As I had figured out that the technical realization for a C++ script, which supports the full feature set and syntax of modern C++, is completely unclear for now or a way more too complex (see blog post), I deferred that task for somewhen unspecified in the future.
Instead, I had a look at how C++ software can be made scriptable, because I was and still am absolute sure that there is a high need of that and there are existing a lot of use cases.
That is because C++ is strongly statically typed at compile time, which is good in general but leads to less flexibility for dynamic extension at runtime. The burden of compile, test and rollout everything is very high if you just want to change a small and tiny part of the application.
(UPDATE) So, the idea is to have 1 to N customization points in the C++ application which can be extended dynamically by a script file. With this the application does not need to be re-compiled and rollout again. Just modify the small script part. Read more on the main page “in a nutshell”.
After my research I realized that there are only 2 options available which are worth to mention. It must be a script language available as a C++ Library and which does not need any prior setups or installation on the target system.
Sol2 / Lua
One option is sol2 (https://github.com/ThePhD/sol2) by ThePhD (https://thephd.dev/), which uses Lua as the script language (https://www.lua.org/home.html).
While from my point of view sol2 as a C++ Library is great from the API perspective (but complex also) and personally, I would have also a lot of fun to program scripts in Lua, I really have concerns with using Lua for a wider audience, where the target programmer is not necessarily a programming expert and/or not familiar with Lua.
The Lua syntax is not easy on some aspects, e.g., chunk boundaries might use just a space as a separator (https://www.lua.org/pil/1.1.html).
a = 1 b = a*2 -- ugly, but validAnother example is that the value 0 (zero) evaluates to true and not false in Lua (https://www.lua.org/pil/2.2.html). So, there might be some surprises which will lead to completely unexpected behavior if you are not familiar with Lua yet.
Additionally, the syntax is far away from C++ and the core language features are also different in many ways, which is not bad in general, but when addressing C++ developers, it might be an issue as well.
Well, of course there are more things than the few mentioned here, but I don’t want to go into some deep Lua specific details at this point. For interested readers, the Lua link above has also a really detailed documentation available. It might be of interest – for me it was – to read there more about the Lua programming language.
ChaiScript
The second option is ChaiScript (https://chaiscript.com/index.html) by Jason Turner (https://www.youtube.com/watch?v=CeHSHEZg-PQ) and his brother Jonathan Turner.
Overall ChaiScript is really awesome. Especially the type conversion and function dispatching and overload resolution is really great implemented and rich of features. Actually, to be honest, I am not sure yet, if I will reach the same achieved level with TeaScript (only regarding that specific aspect of the language!). TeaScript is focusing more on other aspects. Later more to that.
But ChaiScript has also drawbacks and things that could be done better. Also, I have a lot of language features in mind, which are not present in ChaiScript.
Beside some smaller issues (e.g., although “header only” libraries are really great because the ease of use, I think ChaiScript became too big already for be only “header only”) it is lacking a lot of features in the area of parallel / multithreaded execution and is also lacking modern programming language features. You can easily see, that ChaiScript is already a bit out of date and the feature set was designed as C++11 was state of the art (or maybe even before). In the meanwhile, not only C++ was developed further but there is also a series of completely new languages coming with tons of new and modern programming features (mentioning here especially Rust, Zig, Julia, Go and TypeScript).
But more important, I also discovered some technical issues and drawbacks in the underlying software architecture. The biggest are:
- The parser must be fed with syntactical complete blocks, e.g., a complete top-level if-else-if-else-statement with all its inner content. So, the best way is always to feed the complete script in one chunk which then will be parsed also completely at once. But that approach makes some use cases impossible or unusable in practice (e.g., if the script source is not completely available yet or other partial parsing/evaluation scenarios).
- It uses a recursive way for the evaluation of the AST (Abstract Syntax Tree). While this is not necessarily an issue if you just and only want to evaluate the complete script, it becomes a real issue and might be impossible to implement if you want to stop the script in the middle of something and continue it exactly at the same place with exactly the same state later on.
TeaScript will address all of this issues, especially it will come with a different underlying software architecture for make the technical drawbacks absent at all.
Regarding the technical aspects of parsing the script code and AST evaluation watch out the series of upcoming Blog posts from time to time.
Conclusion
Finally, I come to the conclusion that there is a need and also a room for a 3rd option and I made the decision to invent and implement TeaScript to address it.