From: "Ludovic Courtès" <ludo@gnu.org>
To: Ekaitz Zarraga <ekaitz@elenq.tech>
Cc: 73188@debbugs.gnu.org
Subject: bug#73188: PEG parser does not support full PEG grammar
Date: Mon, 14 Oct 2024 13:56:04 +0200 [thread overview]
Message-ID: <875xpu3nl7.fsf@gnu.org> (raw)
In-Reply-To: <168e01eb-ac58-4d39-a960-46624e65edde@elenq.tech> (Ekaitz Zarraga's message of "Sun, 13 Oct 2024 22:59:22 +0200")
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’.
next prev parent reply other threads:[~2024-10-14 11:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-11 22:03 bug#73188: PEG parser does not support full PEG grammar Ekaitz Zarraga
2024-09-12 20:57 ` bug#73188: [PATCH v2] PEG: Add full support for PEG + some extensions Ekaitz Zarraga
2024-10-13 20:29 ` bug#73188: PEG parser does not support full PEG grammar Ludovic Courtès
2024-10-13 20:59 ` Ekaitz Zarraga
2024-10-14 11:56 ` Ludovic Courtès [this message]
2024-10-14 14:00 ` Ekaitz Zarraga
2024-10-11 12:31 ` bug#73188: [PATCH] PEG: Add support for `not-in-range` and [^...] Ekaitz Zarraga
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875xpu3nl7.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=73188@debbugs.gnu.org \
--cc=ekaitz@elenq.tech \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).