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

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> E.g. we could have a PEX of the form (re FORM) where FORM can be any
>> ELisp expression that returns a regular expression.  Then `org-ql.el`
>> could do
>>
>>     (let ((predicate-re (regexp-opt predicate-names)))
>>       (peg-parse
>>           ((query (+ term
>>                      (opt (+ (syntax-class whitespace) (any)))))
>>            [...]
>>            (predicate (re predicate-re))
>>            [...])))
>
> That would be helpful, yes.

Thanks, I'll think about what can be done here.

>> PS: BTW, regarding your comment:
>>
>>         ;; Sort the keywords longest-first to work around what seems to be an
>>         ;; obscure bug in `peg': when one keyword is a substring of another,
>>         ;; and the shorter one is listed first, the shorter one fails to match.
>>
>> The behavior you describe indeed seems like a bug, but maybe what you
>> see is slightly different (and not a bug): if you have a PEX like
>> (and (or "foo" "foobar") "X")
>> the "foo" will match when faced with "foobarX" and the parser won't
>> backtrack to try and match the "foobar" when the "X" fails to match.
>
> Hmm, thanks.  I think an example of the problem is that a predicate in
> org-ql might have a shorter alias, e.g. "heading" is has the alias
> "h", and predicates are followed by arguments, like "heading:foo", so
> IIRC, without sorting them there, "heading:foo" would work, while
> "h:foo" wouldn't.

Odd.  If you have (or "h" "header") in the grammar then I'd expect
"h:foo" to be recognized but "heading:foo" to be rejected (IOW, that
would be a bug in the grammar rather than in `peg.el`).

But you describe the exact opposite for which I don't have
an explanation.  So maybe it's a bug in `peg.el`.  Could you try and
distill it into a bug report?


        Stefan