On 6/22/06, Greg Buchholz <[EMAIL PROTECTED]> wrote:
Ralf Hinze wrote:
> Also, in a non-strict language recursive definitions are not
> limited to function types. Users of parser combinators heavily rely
> on this feature. Just try to define/use parsing combinators
> ins a strict language.
Anyone care to comment on what goes wrong with parser combinators in
an eager language? Is it mainly a space usage problem (where the lazy
version might essentially perform a depth-first-search, while the eager
version is breadth-first)? Or is there something else I'm missing?
Slide 22 ("Combinator Libraries") of
http://research.microsoft.com/~simonpj/papers/haskell-retrospective/
shows that in an eager language, you have to make the argument
explicit, which destroys the Parser abstraction. Indeed I rolled my
own sort of monads and made my own parser combinators in C# and they
were a lot like your Perl combinators: very imperative and verbose
(~10x more code than Haskell for the same parser), instead of clean
and declarative like BNF or Haskell parser combinators.
Jared.
As a reference, back when I was trying to understand monads, I
ported the parser combinators from the Hutton and Meijer paper to
perl...
http://sleepingsquirrel.org/monads/parser/monad_parser.txt
Thanks,
Greg Buchholz
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
http://www.updike.org/~jared/
reverse ")-:"
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
