Re: New package emacs-parser-generator

[Eli Zaretskii]

> From: Daniel Martín <mardani29@yahoo.es>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  Eli Zaretskii
>  <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Mon, 29 Nov 2021 00:46:09 +0100
> 
> I think the main question is not about this library vs. Tree-sitter.  We
> can have both.  But IMO we should spend some time investigating if a
> common API is possible and makes sense.  To the untrained eye, both
> libraries solve the problem of generating parsers for languages, and the
> use cases seem to be more or less the same, so maybe there's an
> opportunity to abstract what's common:
> 
> - Create a parser from a grammar (the way grammars are defined differs).
> - Parse a region of text and generate a syntax tree.
> - Query the syntax tree.
> - etc.

I'm not sure this is the correct approach to the issue.  We should
instead to ask ourselves: "what information would Emacs want from a
parser for use in features like indentation, syntax highlight,
refactoring, etc.", and devise the APIs that would be convenient and
would make sense for those Emacs jobs.  The kind of information and
data that a parser can provide should be considered in the light of
those Emacs requirements, and then we have a better chance of coming
up with common APIs.

> One thing I saw in the in-progress Tree-sitter ELisp API is that it
> feels a bit too coupled to Tree-sitter.  I think in the long run it's
> better for Emacs to have an abstract API similar to the package you
> propose here, where Tree-sitter could be one possible alternative
> implementation.

That's true and agreed, but until someone comes up with at least one
more parser and proposes a common API, discussing this will tend to be
academic, I think.