RE: Parser.y rewrite with parser combinators

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. It's a tricky area though; e.g. the layout rule. Worth talking to Simon Marlow. Simon | -Original Message- | From: ghc-devs On Behalf Of Vladislav | Za

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 is

RE: Parser.y rewrite with parser combinators

that purpose it works really well. From: Iavor Diatchki Sent: 08 October 2018 23:00 To: Simon Peyton Jones Cc: vlad.z.4...@gmail.com; ghc-devs Subject: Re: Parser.y rewrite with parser combinators Hello, my experience with complex parsers written using parsing combinators is that they tend

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 modifyin

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

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 pa

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 refactor

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 h

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 lang

Re: Parser.y rewrite with parser combinators

> I'm also not sure what exactly parser combinators provide over Happy. Parser combinators offer backtracking. With 'happy' we get the guarantee that we parse in linear time, but we lose it because of post-processing that is not guaranteed to be linear. I think it'd be easier to backtrack in the p

Re: Parser.y rewrite with parser combinators

> For example, if we see `do K x y z ...`, we don't know whether we're parsing > an expression or a pattern before we can see what's in the ..., which is > arbitrarily later than the ambiguity starts. Of course, while we can write a > backtracking parser with combinators, doing so doesn't seem l

Re: Parser.y rewrite with parser combinators

Am Di., 9. Okt. 2018 um 00:25 Uhr schrieb Vladislav Zavialov < vlad.z.4...@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 LAL

Re: Parser.y rewrite with parser combinators

Am Di., 9. Okt. 2018 um 09:18 Uhr schrieb Vladislav Zavialov < vlad.z.4...@gmail.com>: > [...] With parser combinators > > 1. Parse into an expression (linear in the amount of tokens) > 2. If it turns out we needed a pattern, backtrack and parse into a > pattern (linear in the amount of tokens) [.

Re: Parser.y rewrite with parser combinators

> 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 la

Re: Parser.y rewrite with parser combinators

> backtrack while backtracking <...> I can almost guarantee that this will > happen unless you use formal methods That is a great idea, I can track backtracking depth in a type-level natural number and make sure it doesn't go over 1 (or add justification with performance analysis when it does).

RE: Parser.y rewrite with parser combinators

I’d never thought of it that way before – interesting. Simon From: ghc-devs On Behalf Of Sven Panne Sent: 09 October 2018 08:23 To: vlad.z.4...@gmail.com Cc: GHC developers Subject: Re: Parser.y rewrite with parser combinators Am Di., 9. Okt. 2018 um 00:25 Uhr schrieb Vladislav Zavialov mailt

Re: Parser.y rewrite with parser combinators

ell in the long run for larger projects... > > I’d never thought of it that way before – interesting. > > > > Simon > > > > From: ghc-devs On Behalf Of Sven Panne > Sent: 09 October 2018 08:23 > To: vlad.z.4...@gmail.com > Cc: GHC developers > Subject: Re

Re: Parser.y rewrite with parser combinators

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 On Behalf Of Sven Panne >> Se

Re: Parser.y rewrite with parser combinators

>> 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... > >> > >

Re: Parser.y rewrite with parser combinators

Am Di., 9. Okt. 2018 um 15:45 Uhr schrieb Richard Eisenberg < r...@cs.brynmawr.edu>: > [...] What I'm trying to say here is that tracking the backtracking level > in types doesn't seem like it will fly (tempting though it may be). > ... and even if it did fly, parser combinators with backtracking

Re: Parser.y rewrite with parser combinators

On Tue, Oct 9, 2018 at 1:09 PM Vladislav Zavialov wrote: > In fact, we do have a fair share of boilerplate in our current grammar > due to lack of parametrisation. That's another issue that would be > solved by parser combinators (or by a fancier parser generator, but > I'm not aware of such one)

Re: Parser.y rewrite with parser combinators

I personally love to hack things up with parser combinators, but for anything longer term where I want a degree of confidence that changes aren't going to introduce new problems I'd still use Happy. Yes it's a total pain sometimes, and LALR(1) is very restrictive, but I wouldn't want to lose the gu