Using the wisent parser-generator, as it creates faster parsers

[ambulajan@gmail.com]

A follow-up note after reading earlier discussion with a subject "Re:
Why tree-sitter instead of Semantic?".

> If you want to build a parser that sits on the lexer, there is more
> to it, as I recommend using the wisent parser-generator, as it
> creates faster parsers. In the wisent .wy files, you define %tokens
> using a bison-like syntax, and that in turns builds analyzers that
> you include in your lexer.

I doubt that the problem of Semantic parsers was ever in Elisp being
slow for that purpose.
For me it was writing a LALR parser. Everything else was logical -
lexers, SemanticDB, etc. But a grammar in development that stalls at
every step with shift/reduce and reduce/reduce conflicts is like
pushing against a wall. LALR algorithm never meant to be an interface
for a developer, rather a workaround for slow CPUs with small memory
systems of the 1980s.

I've written an Earley parser, and so far it looks in the same
performance category as LALR(wisent) written in Elisp.
Earley parser works with any grammar you throw at it. No conflicts.
Each token gets full context of rules that are in effect at that point.
Seems like there's no need to build parse trees, a list of states-
tokens can be thought of as a flattened parse tree.
Though there's a lot of testing for this concept ahead.

Semantic is the only such a system that's conceptualized as
approachable(in Emacs way). Everything else is some combination of
"black boxes" connected with wires.
Lexers can be created with "block" tokens, when function's body is
consumed as one token. Potentially it allows invocation of a parser
with different variants of lexers - one mode with block tokens for the
exploration of project's structure, and another mode for indentation
and error checking purposes.