Combining two threads... Like macros and preprocessors, Happy generates code. I assume the justification for this is that hand-coding a parser in Haskell is presumed to be too difficult or that it is too hard to get the right level of abstraction (and therefore a macro-like facility is required). However, I've also used Hutton & Meijer style monadic parsers and found them extremely elegant, clean, and easy to use in both Haskell and Python (though in Python they were too slow for my xml application -- function call overhead is _very_ high in Python). I am not a parsing expert, but given the recent discussion on macros, I have to ask: why use happy rather than monadic parsing? Monadic parsing allows you to avoid a whole additional language/compilation step and work in Hugs (where you don't have a makefile). What does Happy buy you here? <goingovermyhead> And generalizing from the above, since Monads/Arrows are types that describe a computation declaratively and Macros are functions that describe a computation procedurally, is it possible that, for any application of Macros, you can find a suitable Monad/Arrow? Or am I not understanding either well enough? </goingovermyhead> -Alex- ___________________________________________________________________ S. Alexander Jacobson Shop.Com 1-646-638-2300 voice The Easiest Way To Shop (sm)

Thomas Johnsson <johnsson@crt.se> wrote,

Happy and others like it generate an LR parser, which is a well-established technology since the late 60's (Knuth): efficient, deterministic, and checks the grammar for you. Parser combinators are usually nondeterministic ie backtracking (pre-Knuth!:-) though Cleverly Disguised in Haskell Higher Order clothes.... [..] PS would be cool to try to marry the two approaches....

Doaitse Swierstra et al have done this to a certain extent: http://www.cs.uu.nl/groups/ST/Software/UU_Parsing/ Parser combinators that are efficient, deterministic, and handle errors much better than the classic form of parser combinators. Manuel