When I was ins earch for material about writing a parser for C++ and also had a look at ANTLR and the other parser frameworks, it seemed to be easier and way better to write that from scratch on your own. I choosed an LR(1) parser model as the base technology to go for and wrote some utility classes around that in my generic parser library to helpt with streaming characters, handling UTF8 and so on so that it is after some weeks of putting work into it, to build a parser for almost everything you can think of and store the resulting tokens into whatever structure I like, JSON DOM, HTML, and also convert them into an AST is quite easy now.

However, after attending this thread and for the fact of my exessive use of IL in past few days, I find it very useful to have an option to dynamically generate OpCodes during runtime to achieve for example specialized serialization code without running into too much type reflection. An own VM/ CLR embedded into the engine might be small price for preventing some pain in the future.

Anyways, I put it into my list for the upcoming refactor ?

Kaptein said:

Based on what you have said so far, I would recommend ANTLR, which is sadly written in Java. However, it's a powerful grammatical tool that you can use to transpile your grammar to a real programming language, such as C++.

https://github.com/antlr/antlr4​​ https://github.com/antlr/grammars-v4​​

With that you can build your simple language. No need for a virtual machine.

Thanks the suggestions, but again I'm just keep rolling my own solution for now. So if I were to convert to an existing language, I would also do it myself. Which in case of C/C++ I wouldn't do as I explained because I don't want to keep compile-times of the scripts to a minimum, and even so with how the language supports delays/supension as a core-feature its also way easier for me to make an OpCode for suspension and save the content of my stack instead of having to fiddle around with suspending the whole call-frame in some other language.

Shaarigan said:
However, after attending this thread and for the fact of my exessive use of IL in past few days, I find it very useful to have an option to dynamically generate OpCodes during runtime to achieve for example specialized serialization code without running into too much type reflection. An own VM/ CLR embedded into the engine might be small price for preventing some pain in the future.

Yeah, thats kind of also my thinking. Also, since I'm using a visual frontend the “grammar” is basically laid out and I'm going for more of an imperative approach where an “intrinsic” node would simply instruct the generator to compile the bytecode it represents:

registerIntrinsicCommand<int(int, int)>([](const CompilationConstCallContext& ctx)
{
	ctx.AccessAttributes(); // evaluates input-connections and results with I(0) and I(1) being on the stack

	ctx.Generator<int>().WriteAdd();
}, strFilter, L"AddInt");

This is enough for now, even with control-flow/jumps and simple optimizations (as again the visual frontend already makes it easy to see what is a constant value, which code-paths are used etc…). If I ever wanna do a more aggressive optimization-approach or run into and bumps, I can always add some AST in the background (with minimal refactoring for intrinsics I suppose).