<div dir="ltr">Hello,<div><br></div><div>my experience with complex parsers written using parsing combinators is that they tend to be quite difficult to modify and have any kind of assurance that now you haven't broken something else. While reduce-reduce errors are indeed annoying, you at least know that there is some sort of issue you need to address. With a combinator based parser, you basically have to do program verification, or more pragmatically, have a large test suite and hope that you tested everything.</div><div><br></div><div>I think the current approach is actually quite reasonable: use the Happy grammar to parse out the basic structure of the program, without trying to be completely precise, and then have a separate pass that validates and fixes up the results. While this has the draw-back of some constructors being in the "wrong place", there are also benefits---namely we can report better parse errors. Also, with the new rewrite of HsSyn, we should be able to mark such constructors as only usable in the parsing pass, so later passes wouldn't need to worry about them.</div><div><br></div><div>-Iavor</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 8, 2018 at 2:26 PM Simon Peyton Jones via ghc-devs <<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm no parser expert, but a parser that was easier to understand and modify, and was as fast as the current one, sounds good to me.<br>
<br>
It's a tricky area though; e.g. the layout rule.<br>
<br>
Worth talking to Simon Marlow.<br>
<br>
Simon<br>
<br>
<br>
<br>
| -----Original Message-----<br>
| From: ghc-devs <<a href="mailto:ghc-devs-bounces@haskell.org" target="_blank">ghc-devs-bounces@haskell.org</a>> On Behalf Of Vladislav<br>
| Zavialov<br>
| Sent: 08 October 2018 21:44<br>
| To: ghc-devs <<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>><br>
| Subject: Parser.y rewrite with parser combinators<br>
| <br>
| Hello devs,<br>
| <br>
| Recently I've been working on a couple of parsing-related issues in<br>
| GHC. I implemented support for the -XStarIsType extension, fixed<br>
| parsing of the (!) type operator (Trac #15457), allowed using type<br>
| operators in existential contexts (Trac #15675).<br>
| <br>
| Doing these tasks required way more engineering effort than I expected<br>
| from my prior experience working with parsers due to complexities of<br>
| GHC's grammar.<br>
| <br>
| In the last couple of days, I've been working on Trac #1087 - a<br>
| 12-year old parsing bug. After trying out a couple of approaches, to<br>
| my dismay I realised that fixing it properly (including support for<br>
| bang patterns inside infix constructors, etc) would require a complete<br>
| rewrite of expression and pattern parsing logic.<br>
| <br>
| Worse yet, most of the work would be done outside Parser.y in Haskell<br>
| code instead, in RdrHsSyn helpers. When I try to keep the logic inside<br>
| Parser.y, in every design direction I face reduce/reduce conflicts.<br>
| <br>
| The reduce/reduce conflicts are the worst.<br>
| <br>
| Perhaps it is finally time to admit that Haskell syntax with all of<br>
| the GHC cannot fit into a LALR grammar?<br>
| <br>
| The extent of hacks that we have right now just to make parsing<br>
| possible is astonishing. For instance, we have dedicated constructors<br>
| in HsExpr to make parsing patterns possible (EWildPat, EAsPat,<br>
| EViewPat, ELazyPat). That is, one of the fundamental types (that the<br>
| type checker operates on) has four additional constructors that exist<br>
| due to a reduce/reduce conflict between patterns and expressions.<br>
| <br>
| I propose a complete rewrite of GHC's parser to use recursive descent<br>
| parsing with monadic parser combinators.<br>
| <br>
| 1. We could significantly simplify parsing logic by doing things in a<br>
| more direct manner. For instance, instead of parsing patterns as<br>
| expressions and then post-processing them, we could have separate<br>
| parsing logic for patterns and expressions.<br>
| <br>
| 2. We could fix long-standing parsing bugs like Trac #1087 because<br>
| recursive descent offers more expressive power than LALR (at the cost<br>
| of support for left recursion, which is not much of a loss in<br>
| practice).<br>
| <br>
| 3. New extensions to the grammar would require less engineering effort.<br>
| <br>
| Of course, this rewrite is a huge chunk of work, so before I start, I<br>
| would like to know that this work would be accepted if done well.<br>
| Here's what I want to achieve:<br>
| <br>
| * Comparable performance. The new parser could turn out to be faster<br>
| because it would do less post-processing, but it could be slower<br>
| because 'happy' does all the sorts of low-level optimisations. I will<br>
| consider this project a success only if comparable performance is<br>
| achieved.<br>
| <br>
| * Correctness. The new parser should handle 100% of the syntactic<br>
| constructs that the current parser can handle.<br>
| <br>
| * Error messages. The new error messages should be of equal or better<br>
| quality than existing ones.<br>
| <br>
| * Elegance. The new parser should bring simplification to other parts<br>
| of the compiler (e.g. removal of pattern constructors from HsExpr).<br>
| And one of the design principles is to represent things by dedicated<br>
| data structures, in contrast to the current state of affairs where we<br>
| represent patterns as expressions, data constructor declarations as<br>
| types (before D5180), etc.<br>
| <br>
| Let me know if this is a good/acceptable direction of travel. That's<br>
| definitely something that I personally would like to see happen.<br>
| <br>
| All the best,<br>
| - Vladislav<br>
| _______________________________________________<br>
| ghc-devs mailing list<br>
| <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
| <a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask" rel="noreferrer" target="_blank">https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask</a><br>
| <a href="http://ell.org" rel="noreferrer" target="_blank">ell.org</a>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-<br>
| devs&data=02%7C01%7Csimonpj%<a href="http://40microsoft.com" rel="noreferrer" target="_blank">40microsoft.com</a>%7C19181de5c6bd493ab07a08d<br>
| 62d5edbe0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636746282778542095<br>
| &sdata=lFRt1t4k3BuuRdyOqwOYTZcLPRB%2BtFJwfFtgMpNLxW0%3D&reserved=<br>
| 0<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>