a .NET hosted scripting language with a focus on meta-programming and embedded DSLs
New Prexonite version: (Release v1.90 on GitHub (src+bin))
The first step on the way to Prexonite 2, which is defined by three rather large features:
The Prexonite 1.90 runtime and compiler support sharing in-memory code with multiple applications. This in and itself may sound rather dull, as it only seems to come in handy in REP-loop and plugin-scenarios. It actually solves two problems that have plagued Prexonite since its inception:
Two independent libraries can now define
function open
without having to resort to hard-to-debug shadow ids or cumbersome idioms like
function my_library_open as open
In addition, modules (the shared part of an application) are identified by a name and a version number (major.minor.build.revision, major and minor are mandatory, no associated semantics)
Unfortunately, this new features changes some of the core assumptions in both the Prexonite Script compiler and the Prexonite runtime. This also entails a number of breaking changes in the API. At least most of these also actually break your source code forcing you to adapt : )
On the other hand, it paves the way for making offline-compiled Prexonite applications useful. The quest for a blazingly fast start-up time for Prx.exe has just begun.
Prexonite Script just got support for namespaces, making the limited symbolic namespace mostly a thing of the past. Namespaces are primarily a compiler feature. With the exception of reflection, they have no influence on the execution of a Prexonite program. Nonetheless, namespaces will change the way Prexonite Script is written.
namespace your.awesome.tool
import sys.text, // same as sys.text(*)
sys.seq(*, not map, to_list => all)
{
namespace internal
{
function hello() { println("hello"); }
} //by default, everything is exported
function is_awesome() { internal.hello(); }
} export(*, not internal); //export everything except internal
// the main function must not be inside a namespace, for now
function main() { your.awesome.tool.is_awesome(); }
Namespaces can also re-export symbols from other namespaces. See Prexonite/prxlib/sys.pxs for examples of this.
## Plans
Modules (shared code) and namespaces together enable something that I wanted to provide for a long time: A standard library for Prexonite Script. Up until now that was not really feasible because of the tight namespaces and the large amount of time Prexonite needs to compile a large-ish library.
That last part may come as a surprise, but if you compare the startup-time of programs that use psr\macro.pxs with ones that don’t, you will quickly see where this will lead with libraries that are larger than psr\macro.pxs. True, macro.pxs is not exactly standard, as its implementation heavily relies on macros, but I have no reason to believe that future libraries, including a “standard library” won’t rely on macros, especially with my plans to move more hardwired compiler-functionality into macros.
A standard library as described above has yet to be implemented, however, the necessary mechanisms are in place and are being used to provide symbols for commands that exist today. They mostly live in the sys namespace, though some of them have been put into separate namespaces. See Prexonite/prxlib/sys.pxs for details on where to find what.
Between my Master’s thesis and work, I might just find a handful of minutes to elaborate on the new features. For now, this hasty copy of my notes will have to do.