> 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 language that has a context-free grammar
would be superb. The issue is that Haskell with GHC extensions is
already far from this point and it isn't helping to first pretend that
it is, and then do half of the parsing in post-processing because it
has no such constraints.
On Tue, Oct 9, 2018 at 10:23 AM Sven Panne <svenpa...@gmail.com> wrote:
>
> 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 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.
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Reply via email to