Parser.y rewrite with parser combinators

Simon Peyton Jones simonpj at microsoft.com
Tue Oct 9 10:52:49 UTC 2018


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...
I’d never thought of it that way before – interesting.

Simon

From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Sven Panne
Sent: 09 October 2018 08:23
To: vlad.z.4096 at gmail.com
Cc: GHC developers <ghc-devs at haskell.org>
Subject: Re: Parser.y rewrite with parser combinators

Am Di., 9. Okt. 2018 um 00:25 Uhr schrieb Vladislav Zavialov <vlad.z.4096 at gmail.com<mailto: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/7781d001/attachment.html>


More information about the ghc-devs mailing list