Re: Make peg.el a built-in library?

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Ihor Radchenko <yantar92@posteo.net> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Would the maintainers consider moving this into Emacs proper? I ask
>> mostly because this would be very useful to have in Gnus, both to
>> replace the home-made parser in gnus-search.el, and I would hope to
>> parse eg IMAP server responses more fully and reliably.
>
> Is there any progress merging peg.el to Emacs?
> I do not see any obvious blockers in the discussion, but the merge never
> happened?

It certainly did lose momentum. I think there were some issues regarding
implementation and API, some open questions, and then whoever would have
needed to take ownership of the ticket and see it through did not do so.
Probably that should have been whoever opened the bug report to begin
with!

I believe peg.el does a few things in non-standard ways. I'm not very
familiar with parsing expression grammars, and I don't feel qualified to
judge just how non-standard those ways are, and whether it's a real
issue. But if no one has any massive objections (or plausible fixes)
then personally I'd be okay with it going in like this. I'm not a
maintainer though!

I will say that I tried to use PEG to resolve some gruesome text-parsing
issues in EBDB very recently, and failed to make it work in the hour or
two I'd allotted to the problem. The file-comment docs are pretty good,
but I think they would need to be expanded in a few crucial ways,
particularly to help those who don't necessarily know how PEGs work.

Specifically, it is not obvious (to me) the ways in which PEGs (or maybe
just peg.el) are not fully declarative. It doesn't backtrack, and I
suspect it won't ever backtrack or isn't even supposed to, which means
users should be made explicitly aware of the ways in which their rules
can fail, and the ways in which declaration order matter. The comment
for the `or' construct reads:

Prioritized Choice

And that's about the only hint you get. I was trying to parse a
multiword name like

Eric Edwin Abrahamsen

into the structure

(("Eric" "Edwin") "Abrahamsen")

using rules like

(plain-name (substring (+ [word])) (* [space]))
(full-name (list (+ plain-name) plain-name)
    `(names -- (list (butlast names) (car (last names)))))

Which always fails to match because (+ plain-name) is greedy and eats up
all the words. It doesn't ever try leaving out the last word in an
attempt to make the rule match.

I'm happy to write the docs (should it have its own info manual
section?), if we really think there are no other necessary
fixes/improvements.

Eric