Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)

[S. Alexander Jacobson]

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)