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
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
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
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 – in
e 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...
arger 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: Parser.y rewrite with p
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
> 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).
> 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
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)
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
> 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
ast 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
> | Zavialov
> | Sent: 08 October 2018 21:44
&g
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.
>>>
>>> Si
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
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
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
mon Marlow.
>>
>> Simon
>>
>>
>>
>> | -Original Message-
>> | From: ghc-devs On Behalf Of Vladislav
>> | Zavialov
>> | Sent: 08 October 2018 21:44
>> | To: ghc-devs
>> | Subject: 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
, and for 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
; | From: ghc-devs On Behalf Of Vladislav
> | Zavialov
> | Sent: 08 October 2018 21:44
> | To: ghc-devs
> | Subject: Parser.y rewrite with parser combinators
> |
> | Hello devs,
> |
> | Recently I've been working on a couple of parsing-related issues in
> | GHC. I implemented
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
22 matches
Mail list logo
