[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#73188: PEG parser does not support full PEG grammar
From: |
Ludovic Courtès |
Subject: |
bug#73188: PEG parser does not support full PEG grammar |
Date: |
Mon, 14 Oct 2024 13:56:04 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Saluton!
Ekaitz Zarraga <ekaitz@elenq.tech> skribis:
> On 2024-10-13 22:29, Ludovic Courtès wrote:
>> Hi Ekaitz,
>> Ekaitz Zarraga <ekaitz@elenq.tech> skribis:
[...]
>>> It adds support for the missing features (comments, underscores in
>>> identifiers and escaping) while keeping the extensions (dashes in
>>> identifiers, < and <--).
>>>
>>> The naming system tries to be as close as possible to the one proposed
>>> in the paper.
>>>
>>> * module/ice-9/peg/string-peg.scm: Rewrite PEG parser.
>>> * test-suite/tests/peg.test: Fix import
[...]
>> 1. Is the name change for lexical elements (camel case instead of
>> lower-case + hyphens) user-visible? I guess no but better be safe
>> than sorry.
>
> I think they can be, in a very weird way. If using `peg-as-peg` or
> something they can be used, but the ones coming from the PEG in text,
> which makes way more sense written like in the paper. I'm not sure if
> there's another way to make them available, but I don't think there
> is.
>
> I exported `Grammar` as `peg-grammar` because of this. So the users
> should just use `peg-grammar` for their things.
Sounds good. As long as we don’t unwillingly introduce API
incompatibilities, that is fine.
>> 2. Could you add tests for the missing features that this adds, and
>> maybe extend ‘api-peg.texi’ accordingly too?
>
> It doesn't really add much new in this first case, but it makes it
> work as expected in PEG, which is what documentation already claimed
> to do, and the code didn't actually implement. Mostly what this commit
> adds is escaping support in the PEG string literals.
I was referring to the features mentioned in the commit log, namely
comments, underscores in identifiers, and escaping.
>> 3. You can choose to assign copyright to the FSF or to not do that¹.
>> In the latter case, please add a copyright line for you where
>> appropriate.
>
> I don't care (maybe I should?). I just want this to work properly.
So, copyright line I guess. :-)
Thanks,
Ludo’.