[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Redoing the current tag/property parser in a real grammar [was: Re:
From: |
Jens Schmidt |
Subject: |
Re: Redoing the current tag/property parser in a real grammar [was: Re: [RFC] Quoting property names in tag/property matches] |
Date: |
Sat, 2 Sep 2023 15:14:08 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 |
On 2023-09-02 09:10, Ihor Radchenko wrote:
> Jens Schmidt <jschmidt4gnu@vodafonemail.de> writes:
>> This all calls for a proper parser, based on peg or bovine or whatever.
>> Hopefully that parser would still keep backward compatibility, but
>> that's probably wishful thinking.
>
> Backward compatibility will be easy - just leave the current code when
> old query version is detected. We should better focus on the new syntax
> in future and leave the current syntax as compatibility layer that will
> be eventually deprecated.
Agreed except for the deprecation part. I think Org should be big enough
to have two parsers: One along the lines of the current one (infix, DWIM,
easy to type) and one along the lines of org-ql (sexp, better extensible,
more flexible, harder to type). Ideally, it should be even possible to
embed the infix-one into the sexp-one.
It should also be possible to put the current infix parser onto a more
stable ground as well, based on a formal grammar, providing at least
parentheses for grouping and negation, and that without breaking backward
compatibility.
Let's rephrase that way: If I were to redo the current parser as
mentioned in the previous paragraph, would these changes "eventually be
deprecated"? (Which doesn't necessarily mean that I promise to do so,
of course.)