Category:Sparkling: Difference between revisions

Another rarely seen feature is the obligation to declare each local variable used, and the lack of (implied) global variables. All local variables must be declared before they can be referred to (read or written). Undeclared names are assumed to be globals (for practical reasons, i. e. because of the lack of header files), although global objects cannot be modified (they are always constants). The goal of the author with this behavior is to minimize programmer errors and bugs arising out of forgotten declarations and interfering globals.

The reference implementation is written in portable C89: "portable" in the sense that it tries to follow the ANSI C International Standard as strictly as possible. This does not mean, however, that the entire source is compatible with C++. The public API, however, can be used from within a C++ program, though.

Similarly to almost all modern languages, the Sparkling distribution comes with a bunch of utility and run-time support functions bundled in various "packages" of the Sparkling standard library. These packages can be loaded separately by the host program (i. e. the native environment that runs the Sparkling interpreter); in the default mode, however, all standard functions are loaded at the beginning of a Sparkling session (represented by an "SpnContext" object, from an API point of view). Library functions are not special in the sense that they are just normal native extension functions. There is one exception, though: standard library functions assume the use of the context API, and as such, they require their user info argument to point to a valid SpnContext object. This is done so that these functions can use the error reporting facilities of the virtual machine.

Users can write and load native extension functions with the aid of the Sparkling C API. Extension functions must be written in C (or in C++ with external C linkage), and they must follow a predefined signature, which makes it possible for the Sparkling virtual machine to communicate withcall such a function. Function arguments are passed in an array of Sparkling value ("SpnValue") objects, and the return value of a function - as seen by a Sparkling script - should be moved into place using a pointer to another SpnValue. The (actual, integer) return value of athe native function determines whether the virtual machine continues the execution of a program (zero) or raises a runtime exception (non-zero).

Apart from the already mentioned disassembler, the virtual machine provides a basic stack tracing feature, which can be accessed using the C API. For technical reasons, native functions are not included in the stack trace.