headers
S. Alexander Jacobson | 1 Jun 2006 19:18

Re: xml in fptools?

Ok, but my original question is whether one XML tool makes sense.

For example, if we are consuming XML, it seems like we would want 
something layered on top of Parsec or PArrows (so we can also parse 
the contents of CDATA etc).

And, if we are producing XML, then we just need some data type that 
represents the XML infoset and a function for presenting that infoset 
as XML.

And if we are transforming XML, then perhaps the HaXML approach makes 
the most sense.  Note: I am using a wrapper around HaXML for producing 
XML in HAppS.

And if we are *transacting* XML, then a tool like Haifa or HWSProxyGen 
or perhaps DTDToHaskell seems to make the most sense.

All of these seem like different needs/tools.  What were your use-cases?

-Alex-

______________________________________________________________
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

On Wed, 31 May 2006, Graham Klyne wrote:

> Well, part of my point was that, AFAICT, your approach doesn't serve the
> use-cases I envisage and did development for.
>
> It seems to me that a good basic XML parser would be a prerequisite to
(Continue reading)

Permalink | Reply | 2 comments |
headers
S. Alexander Jacobson | 1 Jun 2006 21:23

Re: xml in fptools?

Note, for transforming XML to HTML and MIME, I use XSLT rather than 
Haskell.

-Alex-


On Thu, 1 Jun 2006, S. Alexander Jacobson wrote:

> Ok, but my original question is whether one XML tool makes sense.
>
> For example, if we are consuming XML, it seems like we would want something 
> layered on top of Parsec or PArrows (so we can also parse the contents of 
> CDATA etc).
>
> And, if we are producing XML, then we just need some data type that 
> represents the XML infoset and a function for presenting that infoset as XML.
>
> And if we are transforming XML, then perhaps the HaXML approach makes the 
> most sense.  Note: I am using a wrapper around HaXML for producing XML in 
> HAppS.
>
> And if we are *transacting* XML, then a tool like Haifa or HWSProxyGen or 
> perhaps DTDToHaskell seems to make the most sense.
>
> All of these seem like different needs/tools.  What were your use-cases?
>
> -Alex-
>
> ______________________________________________________________
> S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com
(Continue reading)

Permalink | Reply | 0 comments |
headers
Graham Klyne | 1 Jun 2006 22:02

Re: xml in fptools?

S. Alexander Jacobson wrote:
> Ok, but my original question is whether one XML tool makes sense.

I missed that bit... a fair question, but one that begs "what constitutes a tool?".

I would suggest that XML is sufficiently quirky and complex to parse that we (as
a community) probably don't want to invest effort in supporting more than one
XML *parser*.  But other tools may usefully be layered on top of that parser.

As for the use cases you offer, I think that's one way, but not the only way, to
slice the problem space:

> For example, if we are consuming XML, it seems like we would want
> something layered on top of Parsec or PArrows (so we can also parse the
> contents of CDATA etc).

HaXML is layered on something like that, viz. HMW parser combinators.  I suppose
it could be layered on Parsec, and if starting afresh that might be a good
option, but it doesn't seem to me to be a critical issue.

As for parsing the contents of CDATA sections, I'd suggest that (except for very
specific applications with demanding performance requirements) is something to
be tackled *after* the XML has been parsed.

> And, if we are producing XML, then we just need some data type that
> represents the XML infoset and a function for presenting that infoset as
> XML.

I see *producing* XML as being a different, albeit related, problem to that of
*parsing* XML.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gregory Wright | 2 Jun 2006 03:46
Picon

Re: ANN: Edison 1.2RC4


Hi Robert,

Edison 1.2rc4 builds on OS X 10.4.6/powerpc with ghc 6.4.2
and passes the test suite with no errors.

I have packaged it for the darwinports system, where it can be
obtained as hs-Edison and hs-EdisonAPI.  (It's packaged as
two separate ports so that EdisonAPI is automatically built as
a dependent of Edison.  Users need only install the hs-Edison port.)
You might want to consider distributing Edison's API and core
separately in the future, to make life a bit easier for package
management system like darwinports and FreeBSD ports.

I will update the port to the final release when it comes out.

Best Wishes,
Greg

On May 14, 2006, at 5:36 PM, Robert Dockins wrote:

> Fellow Haskellers!
>
> I am pleased to announce the 4th (and with any luck, final) release  
> candidate
> for Edison 1.2.  Edison is a library of efficient data structures for
> Haskell.
>
> Changes from RC3 include:
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jim Apple | 2 Jun 2006 05:57
Picon

Re: ANN: Edison 1.2RC4

> I am pleased to announce the 4th (and with any luck, final) release candidate
> for Edison 1.2.  Edison is a library of efficient data structures for
> Haskell.

Based on Exercise 10.2 of Okasaki's book

Roughly:
"Reimplement AltBinaryRandomAccessList so that cons, head, and tail
all run in O(1) amortized time, using the type

data RList a =
    Nil
  | One a (RList (a,a))
  | Two a a (RList (a,a))
  | Three a a a (RList (a,a))"

and the source for BinaryRandList at
http://www.eecs.tufts.edu/~rdocki01/edison/_darcs/current/edison-core/src/Data/Edison/Seq/BinaryRandList.hs
, I don't think the constant time bounds in the documentation are
correct for this sequence type.

Jim
Permalink | Reply | 4 comments |
headers
Robert Dockins | 2 Jun 2006 16:26

Re: ANN: Edison 1.2RC4

On Jun 1, 2006, at 9:46 PM, Gregory Wright wrote:

> Hi Robert,
>
> Edison 1.2rc4 builds on OS X 10.4.6/powerpc with ghc 6.4.2
> and passes the test suite with no errors.

Excellent.

> I have packaged it for the darwinports system, where it can be
> obtained as hs-Edison and hs-EdisonAPI.  (It's packaged as
> two separate ports so that EdisonAPI is automatically built as
> a dependent of Edison.  Users need only install the hs-Edison port.)
> You might want to consider distributing Edison's API and core
> separately in the future, to make life a bit easier for package
> management system like darwinports and FreeBSD ports.

Even better! Thanks for doing this.

What would be the preferred format for separate distribution  
packages?  The thing that immediately comes to mind is to just take  
the standard distribution and delete irrelevant subdirectories.

> I will update the port to the final release when it comes out.
>
> Best Wishes,
> Greg
>
>
> On May 14, 2006, at 5:36 PM, Robert Dockins wrote:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Robert Dockins | 2 Jun 2006 16:34

Re: ANN: Edison 1.2RC4


On Jun 1, 2006, at 11:57 PM, Jim Apple wrote:

>> I am pleased to announce the 4th (and with any luck, final)  
>> release candidate
>> for Edison 1.2.  Edison is a library of efficient data structures for
>> Haskell.
>
> Based on Exercise 10.2 of Okasaki's book
>
> Roughly:
> "Reimplement AltBinaryRandomAccessList so that cons, head, and tail
> all run in O(1) amortized time, using the type
>
> data RList a =
>    Nil
>  | One a (RList (a,a))
>  | Two a a (RList (a,a))
>  | Three a a a (RList (a,a))"
>
> and the source for BinaryRandList at
> http://www.eecs.tufts.edu/~rdocki01/edison/_darcs/current/edison- 
> core/src/Data/Edison/Seq/BinaryRandList.hs
> , I don't think the constant time bounds in the documentation are
> correct for this sequence type.

Ah, I see.  I know we've discussed this implementation before, but it  
didn't quite become apparent to me that the documentation was in  
error.  Does Okasaki say what the bounds should be for this  
implementation?  I imagine it's O(log n), but my lazy-amortized-
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jim Apple | 2 Jun 2006 16:31
Picon

Re: ANN: Edison 1.2RC4

On 6/2/06, Robert Dockins <robdockins <at> fastmail.fm> wrote:
> Does Okasaki say what the bounds should be for this
> implementation?  I imagine it's O(log n), but my lazy-amortized-
> complexity-analysis-fu isn't very good...

I don't have the book out from the library anymore. Anybody?

There's also a paper & a thesis he wrote covering much of the same
material. Some of the bounds might be in there.

We should probably also check the other exercises in the book to make
sure the other bounds listed in the Haddock documentation for the
other data structures are correct.

Jim
Permalink | Reply | 1 comment |
headers
Robert Dockins | 2 Jun 2006 16:48

Re: ANN: Edison 1.2RC4


On Jun 2, 2006, at 10:31 AM, Jim Apple wrote:
> On 6/2/06, Robert Dockins <robdockins <at> fastmail.fm> wrote:
>> Does Okasaki say what the bounds should be for this
>> implementation?  I imagine it's O(log n), but my lazy-amortized-
>> complexity-analysis-fu isn't very good...
>
> I don't have the book out from the library anymore. Anybody?
>
> There's also a paper & a thesis he wrote covering much of the same
> material. Some of the bounds might be in there.

I'll look around and see what I can find.  As I recall, he doesn't  
specifically mention the bounds for these operations for this  
implementation, but it's been a little while since I looked.

> We should probably also check the other exercises in the book to make
> sure the other bounds listed in the Haddock documentation for the
> other data structures are correct.

That's a good idea.  I'll do a quick audit before the release to see  
if I can spot any other obvious errors.

> Jim

Rob Dockins

Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
           -- TMBG
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ross Paterson | 2 Jun 2006 17:32
Picon
Favicon

Re: ANN: Edison 1.2RC4

On Thu, Jun 01, 2006 at 11:57:47PM -0400, Jim Apple wrote:
> the source for BinaryRandList at
> http://www.eecs.tufts.edu/~rdocki01/edison/_darcs/current/edison-core/src/Data/Edison/Seq/BinaryRandList.hs
> , I don't think the constant time bounds in the documentation are
> correct for this sequence type.

Indeed not.  If you have a sequence of exactly 2^n elements and then
alternate between tail and cons, each operation will cost O(log n).
Permalink | Reply | 0 comments |

Gmane