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

[Adam Porter]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> The peg-allow-symbols patch is more tentative. The issue is that _all_
>> of the entry-points to peg code are macros, meaning you can't build your
>> grammar up in a variable, and then pass that variable to any of
>> `peg-run', `peg-parse', `with-peg-rules', etc. Nobody will evaluate the
>> variable; you have to literally write the rules inside the
>> `with-peg-rules' form. It seems like a fairly plausible use-case to
>> store the rules in a variable or an option, even if you're not doing
>> run-time manipulation of them. The only solution, as Adam found with
>> org-ql, is to `eval' one of the macros.
>>
>> This doesn't seem necessary! The patch has `with-peg-rules' check if the
>> rules are a symbol, and take the `symbol-value' if so. But I wonder if
>> it wouldn't be nicer to break some of the code out: `peg-normalize'
>> seems to be the entry-point for "compile this grammar", and that could
>> be modified to work the way that some languages provide for pre-compiled
>> regexps: a way to let the developer build and compile the grammar at
>> load-time or launch-time, then feed the stored compiled version to
>> parsing routines.
>
> `peg` is the macro that's supposed to be this compilation step: you pass
> it a PEX and you receive a value in return.  It's a bit like `lambda`.
>
> You can then use this value (a "peg matcher") to parse something by
> passing it to `peg-run`.
>
> So you can do
>
>     (let ((parser (peg PEX)))
>       ...
>       (peg-run parser ...)
>       ...)
>
> What might still be missing, tho is a way to invoke this `parser` from
> within a PEX.  So we might want to add a new PEX form that would be akin
> to `funcall`.  We could name it `call`:
>
>     (let* ((parser (peg PEX))
>       ...
>       (with-peg-rules
>           ((foo ...)
>            (bar ... (call parser) ...)
>            (baz ...))
>         ...))
>
> so (peg-parse (call FORM)) would end up equivalent to (peg-run FORM ...).
> WDYT?

In org-ql, the PEX is redefined at load time and/or run time, being
derived from search keywords that are defined by the package and
possibly by the user.  So the PEX can't be defined in advance, at
compile time.  So having to use `with-peg-rules' means having to use
`eval'.

That's why it would be nice to have a `peg' function that could be
called with a PEX form, to return a function that could be stored in a
variable and later be called with a string argument, that would parse
the string with the PEG.  Sort of like Python's re.compile.