Parser.y rewrite with parser combinators

[Vladislav Zavialov]

> 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

I do agree here! Having a language that has a context-free grammar
would be superb. The issue is that Haskell with GHC extensions is
already far from this point and it isn't helping to first pretend that
it is, and then do half of the parsing in post-processing because it
has no such constraints.
On Tue, Oct 9, 2018 at 10:23 AM Sven Panne <svenpanne at gmail.com> wrote:
>
> 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.