a .NET hosted scripting language with a focus on meta-programming and embedded DSLs
There have not been any significant changes since the introduction of the CIL compiler into the Prexonite, yet the current version comes with a number of performance optimizations regarding the generated CIL byte code.
The majority of the built-in commands and types now use the ICilCompilerAware interface, which is used by the CIL compiler to let commands and types emit highly customized code.
Calling println with no arguments for instance, results in a static call to void System::Console.WriteLine() directly in the compiled method.
Similarly, type expressions in CIL functions are no longer implemented via type expression parsing but by directly referencing the corresponding singleton PType objects.
But the most important improvement is the possibility to statically link Prexonite function calls in CIL compiled methods, which makes yet another hashtable lookup redundant at the cost of additional memory: a dynamically generated class has static fields for each and every function used by the compiled application.
This can be a problem if you plan to re-compile your CIL-implementations, as dynamic type, unlike dynamic functions, cannot be garbage collected by design.
It is, however, possible to disable the generation of such a class by passing false to CompileToCil.
And on a side note: The often used library function struct has been implemented as a compiler hook for improved performance.
By resolving the members at compile time one does not only save run time, but also removes the need for dynamic lookups, which in turn enables the use of CIL compilation for struct-functions.
This is especially helpful for immutable structs.