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

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Adam Porter <adam@alphapapa.net> writes:

> FWIW, I've been happy using peg.el in org-ql.  I use it to parse strings
> like:
>
>   "todo:WAITING scheduled:from=2021-08-01,to=2021-08-31"
>
> into a sexp like:
>
>   (and (todo "WAITING")
>        (scheduled :from "2021-08-01" :to "2021-08-31"))
>
> You can see the code I use here:
>
> https://github.com/alphapapa/org-ql/blob/master/org-ql.el#L854

This is very helpful, thanks. The peg.el comments are not very helpful
when it comes to actions, so it's great to have more examples. I'll try
to provide a comment patch to the library once I've made more progress.

> I can't speak much to its performance, because it's plenty fast enough for the
> relatively light usage it gets in org-ql.  

In gnus-search.el it would be the same situation: performance wouldn't
matter at all. If I can use it for IMAP server parsing, though, it would
be important not to be too slow.

> My only, minor complaint is that I ended up having to use `eval' on
> its `with-peg-rules' macro at runtime:
>
> https://github.com/alphapapa/org-ql/blob/94f9e6f3031b32cf5e2149beca7074807235dcb0/org-ql.el#L908
>
> I tried many, many things before resorting to that, so I don't think I
> missed any alternatives at the time.  If that aspect of the API could be
> improved, it would be welcomed, but I don't think it's necessary to do
> so before adding it to Emacs.
>
> (The issue is that the tokens that are parsed can be added to at
> runtime, so they are stored in a variable, and the parsing function is
> redefined as necessary at runtime, so it's not possible to define the
> parser fully at expansion time.)

This doesn't mean much to me (yet), but I'll keep an eye out!

> Thanks for suggesting this, Eric.  

Thanks for pointing out that it exists!