Re: Parser.y rewrite with parser combinators

I actually have some experience in this department, having authored both madlang and language-ats . Parsers using combinators alone are more brittle than parsers using Happy, at least for human-facing

Re: Parser.y rewrite with parser combinators

Another thing that may be of interest is that parser generators can guarantee you complexity bounds of parsing time (as usual, the goal is linear). Some of the conflicts that annoy us about parser generators are often hints on this topic; if the parser generator succeeds, you are guaranteed to

Re: Parser.y rewrite with parser combinators

I, too, have wondered about this. A pair of students this summer were working on merging the type-level and term-level parsers, in preparation for, e.g., visible dependent quantification in terms (not to mention dependent types). If successful, this would have been an entirely internal

Re: Parser.y rewrite with parser combinators

That is a very good point, thank you! I have not thought about incremental parsing. That's something I need to research before I start the rewrite. On Tue, Oct 9, 2018 at 1:06 AM Alan & Kim Zimmerman wrote: > > I am not against this proposal, but want to raise a possible future concern. > > As

Re: Parser.y rewrite with parser combinators

> 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 That's true regardless of implementation technique, parsers are rather delicate. A LALR-based parser generator does

Re: Parser.y rewrite with parser combinators

I am not against this proposal, but want to raise a possible future concern. As part of improving the haskell tooling environment I am keen on making GHC incremental, and have started a proof of concept based in the same techniques as used in the tree-sitter library. This is achieved by

RE: Parser.y rewrite with parser combinators

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. Incidentally, we use this for operator fixity and precedence, where the fixup is done in the renamer, and for

Re: Parser.y rewrite with parser combinators

Hello, 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

Parser.y rewrite with parser combinators

Hello devs, Recently I've been working on a couple of parsing-related issues in GHC. I implemented support for the -XStarIsType extension, fixed parsing of the (!) type operator (Trac #15457), allowed using type operators in existential contexts (Trac #15675). Doing these tasks required way more