bug-guile
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#73188: PEG parser does not support full PEG grammar


From: Ekaitz Zarraga
Subject: bug#73188: PEG parser does not support full PEG grammar
Date: Sun, 13 Oct 2024 22:59:22 +0200

Saluton Ludovic,

On 2024-10-13 22:29, Ludovic Courtès wrote:
Hi Ekaitz,

Ekaitz Zarraga <ekaitz@elenq.tech> skribis:

This commit adds support for PEG as described in:

     <https://bford.info/pub/lang/peg.pdf>

I would make this a comment below the ‘define-module’ form.

Okay I will add it.

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

Nice work!

Thank you

Questions:

   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.

      I have a preference for lower-case + hyphens out of consistency
      with the rest of Scheme, but I can see how keeping the same names
      as in the reference material helps.

Yeah, I wasn't sure about it. And I'm still not very sure. But I think keeping the same names the paper does helps.

   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.

   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.

I’m really not a PEG expert though so I’d prefer more eyeballs here, but
I trust your judgment.

I don't know how wise this is :)

There are three (guix import *) modules that use (ice-9 peg) and that
come with tests.  It would be nice to check that those tests still pass
with the modified string-peg.scm.

This is very interesting and I didn't know. All tests from Guile pass, but I'll try these and report here.

Thanks!

Ludo’.

¹ https://lists.gnu.org/archive/html/guile-devel/2022-10/msg00008.html


Thanks for the review, Ludo.

Next days I plan to review some older patches in the mailing list that offer a very straightforward solution for error reporting and try to include them with this and the extra features I added.

For the time being, I'll review what you mentioned, rebase the support for `[^...]` and resend them together.

I appreciate your time spent here, Ludo. Really.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]