On 6/22/06, Greg Buchholz
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 ")-:"