Parser.y rewrite with parser combinators

[Sven Panne]

Am Di., 9. Okt. 2018 um 00:25 Uhr schrieb Vladislav Zavialov <
vlad.z.4096 at gmail.com>:

> [...] That's true regardless of implementation technique, parsers are
> rather
> delicate.


I think it's not the parsers themselves which are delicate, it is the
language that they should recognize.


> A LALR-based parser generator does provide more information
> when it detects shift/reduce and reduce/reduce conflicts, but I never
> found this information useful. It was always quite the opposite of
> being helpful - an indication that a LALR parser could not handle my
> change and I had to look for workarounds. [...]
>

Not that this would help at this point, but: The conflicts reported by
parser generators like Happy are *extremely* valuable, they hint at
tricky/ambiguous points in the grammar, which in turn is a strong hint that
the language you're trying to parse has dark corners. IMHO every language
designer and e.g. everybody proposing a syntactic extension to GHC should
try to fit this into a grammar for Happy *before* proposing that extension.
If you get conflicts, it is a very strong hint that the language is hard to
parse by *humans*, too, which is the most important thing to consider.
Haskell already has tons of syntactic warts which can only be parsed by
infinite lookahead, which is only a minor technical problem, but a major
usablity problem. "Programs are meant to be read by humans and only
incidentally for computers to execute." (D.E.K.) </rant> ;-)

The situation is a bit strange: We all love strong guarantees offered by
type checking, but somehow most people shy away from "syntactic type
checking" offered by parser generators. Parser combinators are the Python
of parsing: Easy to use initially, but a maintenance hell in the long run
for larger projects...

Cheers,
   S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20181009/78b6c557/attachment.html>