Parser.y rewrite with parser combinators

[Sven Panne]

Am Di., 9. Okt. 2018 um 15:45 Uhr schrieb Richard Eisenberg <
rae at cs.brynmawr.edu>:

> [...] What I'm trying to say here is that tracking the backtracking level
> in types doesn't seem like it will fly (tempting though it may be).
>

... and even if it did fly, parser combinators with backtracking have a
strong tendency to introduce space leaks: To backtrack, you have too keep
previous input somehow, at least up to some point. So to keep the memory
requirements sane, you have to explicitly commit to one parse or another at
some point. Different combinator libraries have different ways to do that,
but you have to do that by hand somehow, and that's where the beauty and
maintainability of the combinator approach really suffers.

Note that I'm not against parser combinators, far from it, but I don't
think they are necessarily the right tool for the problem at hand. The
basic problem is: Haskell's syntax, especially with all those extensions,
is quite tricky, and this will be reflected in any parser for it. IMHO a
parser generator is the lesser evil here, at least it points you to the
ugly places of your language (on a syntactic level). If Haskell had a few
more syntactic hints, reading code would be easier, not only for a
compiler, but (more importantly) for humans, too. Richard's code snippet is
a good example where some hint would be very useful for the casual reader,
in some sense humans have to "backtrack", too, when reading such code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20181009/105847ca/attachment.html>