Integrate generic script engine: parser generator, AST builder, interpreter core

[ponyatov]

seco lacks of very usable and powerful tool -- syntax parser. With parser you able to input and process any data presented in plain text formats: scripts in any programming languages, JSON, XML,.. any text data formats.

A parser generator is a tool that reads a grammar specification and converts it to a program, library module or executable object that can recognize matches to the grammar. In addition to the parser matcher itself, any parser generator provides other standard capabilities related to parser generation such as AST tree building, actions on matched elements, debugging, etc.

So the most impressive way is expand seco by full set of interpreter design tools: ANTLR parser toolchain, cell editor able to use ANTLRed grammars for syntax highlight (and completion?), grammar set for most used programming and data languages, DLR (Dynamic Language Runtime) for interpreter realization, and vizulatization tools for displaying interpreter internals (for learning for example).

[EBoiSha]

Do I understand it correctly that you want to have a parser created which is able to parse any given input? It would be great if you provide me with a bit more detail and idea, perhaps even a starting point and I would see what I can do.

br

[bolerio]

I can't speak for @ponyatov , but my understanding is that yes, something like antlr where you could specify the grammar of a language, or at least some interesting fragments, will be helpful in creating more intelligent support for various languages. Currently the code completion support we have here and there is based on the internal parsers of the corresponding language. The problem with a generic parser generator is that you have to write a complete grammar, which is quite laborious :) Parsing out fragments only will make it easier to use that tool, but the tool itself will be harder to create.

[axkr]

You mean something like LSP?
https://microsoft.github.io/language-server-protocol/overview

[bolerio]

@axkr that's pretty cool. This goes way beyond parsing since it maintains a complete semantic representation of a source file and exposes a set of predefined operations/queries on it. But it's an interesting idea. The ecosystem of dev tooling has grown so rich that it warrants such a task separation and a protocol etc. But I think that idea of standardizing on the operations available to the editor (provide suggestions, navigate to definition, find usages etc.) is a sound one, definitely. Then a language provider can be implemented for each language. That would be an extension to what we currently do in Seco, which is just a code completion provider.