Re: New package emacs-parser-generator

[Daniel Martín]

Christian Johansson <christian@cvj.se> writes:

> Well the GLR(k) algorithm might find a nondeterminstic route route in
> the grammar that a LR(k) do not find, if I want to know if a code is
> syntatically correct I would test it against the same type of parser
> the language uses, that is a deterministic parser
>
>> 
> An intuitive structure - Tree-sitter’s output is a concrete syntax
> tree; each node in the tree corresponds directly to a terminal or
> non-terminal symbol in the grammar. So in order to produce an
> easy-to-analyze tree, there should be a direct correspondence between
> the symbols in your grammar and the recognizable constructs in the
> language. This might seem obvious, but it is very different from the
> way that context-free grammars are often written in contexts like
> language specifications or Yacc/Bison parsers.
>
>> https://tree-sitter.github.io/tree-sitter/creating-parsers#the-grammar-dsl
>
> This is a big issue because each version of a language grammar would need to 
> be converted into tred-sitter form
>
>
>
> But anyways I don't see the issue with pluralism in the parser
> generator space, why would one exclude the other?

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.

To people much more familiar with this topic, is this an
oversimplification that would led to the wrong abstraction?

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.