Re: New package emacs-parser-generator

[Christian Johansson]

Hi again

My main intention that I forgot to include in the original email was to request 
to include my parser-generator library in GNU ELPA. Stefan requested that to 
solve the dependency-problem with generating the parser for phps-mode.

My library is only elisp and I think treesitter is C-based so treesitter is 
probably faster overall even though a LR(k) should be faster than a GLR(k) 
parser in theory. Especially the lex-analyzer part is slow in my library, also  
generating a parser for a complex language is ridiculously slow. Parsing is 
very fast though

Regards
Christian



> 29 nov. 2021 kl. 13:30 skrev Eli Zaretskii <eliz@gnu.org>:
> 
> 
>> 
>> 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.