Category:Sparkling

This page is a stub. It needs more information! You can help Rosetta Code by filling it in!

Sparkling is an embeddable, extensible, dynamically and strictly typed, C-like scripting language. Created by Árpád Goretity (a. k. a. H2CO3) in late 2013, the aim of the language is to provide an easy-to-use, easy-to-embed, portable scripting engine suited for various purposes.

Design and heritage

The design, syntax and semantics of Sparkling have been influenced by several popular languages, such as C, Python, Lua and JavaScript (the latter being mostly negatively credited). This implies that parts of the language have a lot in common with these technologies. For example, its syntax should be familiar for someone having coded in C or JavaScript, the strict but dynamic type system resembles that of Python, and the "drop-in" library nature of the implementation was admittedly inspired by Lua.

Quite a few design decisions oppose the architecture of the aforementioned languages, though. For example, in contrast with most popular scripting languages, Sparkling has two numeric types. It operates not only on floating-point numbers, but on integers as well. Operations involving both floating-point and integral operands have well-defined semantics, similar to that in C.

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 this behavior is to minimize programmer errors and bugs arising out of forgotten declarations and interfering globals.

The reference implementation

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

Another aspect of portableness or platform-independence is that the Sparkling engine tries to make use of a bunch of convenient libraries in order to improve user experience. For instance, the REPL optionally uses the well-known readline library - if available - in order to provide basic line editing capabilities. Or, on OS X and iOS, the parser and runtime support library conditionally provide Objective-C bindings, so it's possible to call Objective-C methods directly from Sparkling, with proper Objective-C syntax. Neither of these features are required, though, nor do they impose a strong dependency on either libreadline or libobjc. The build system tries to guess if they are available and configures compilation accordingly.

The reference implementation is currently hosted on GitHub, at H2CO3/Sparkling[1].

Syntax and semantics

Sparkling borrows most of its syntax from C and a tiny bit from JavaScript. Semantics also follow a - hopefully - "intuitive" or "expected" convention, so that they're easier to grasp, especially for someone who has programmed before in C, C++, JavaScript or a similar language.

The basic "Hello world" program looks like:

<lang sparkling>print("Hello world!");</lang>

A somewhat more complex (unnecessarily complex for this purpose) version demonstrates some more language elements:

<lang sparkling>const helloWorldString = "Hello, world!";

function printMessage(msg) {

   var numCharsWritten = printf("%s\n", msg);
   printf("%d characters written\n", numCharsWritten);

}

printMessage(helloWorldString);

return 0;</lang>

The output of this program is:

$ spn hello.spn
Hello, world!
14 characters written
$

A full language tutorial is available in the official documentation[2].

The standard library

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.

The currently available standard packages are:

I/O routines (writing/reading to/from standard streams and files)
String manipulation
Array and associative array manipulation
Floating-point, integral and complex mathematical functions
Shell and environment access (including system date and time)

Implementation

Sparkling is an interpreted language, featuring a simple two-pass compiler and a register-based virtual machine. The compiler consists of a purely recursive descent parser and an almost naive (overwhelmingly non-optimizing) code generator, which directly generates bytecode for the VM. The compiler and the parser communicate using a right-leaning, binary abstract syntax tree (AST). The REPL also contains a disassembler which can convert bytecode into an assembly-like, human-readable textual representation.

Despite the fact that the reference implementation imposes an interpreted nature on the language, there are plans aiming to create a just-in-time (JIT) compiler back-end that produces native executable code (rather than bytecode targeting the VM). The implementation of the REPL also features a "compiler" option (-c), which converts Sparkling source files into bytecode files. The format of the bytecode is not portable, so such an "object file" runs only on the platform/architecture it has been compiled on. This is done like so for simplicity and performance reasons: for example, floating-point and integer constants are stored in the bytecode as they are represented in memory, so that there needn't be any - potentially expensive and/or inconvenient to implement - runtime conversions.

Although the primary goal of Sparkling is to be used as an extension language, there is a separate, stand-alone program that comes with the source as well. It contains an interactive interpreter (REPL, read-eval-print loop), a compiler and a disassembler.

Performance

The reference implementation, being an interpreted language, doesn't have an outstandingly good performance. However, its speed is quite decent, and is mostly comparable to that of Lua (which is sometimes considered one of the fastest scripting languages available).

Extensibility

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 call 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 the native function determines whether the virtual machine continues the execution of a program (zero) or raises a runtime exception (non-zero).

Debugging

Apart from the already mentioned disassembler, the virtual machine provides a basic stack tracing feature, which can be accessed using the C API. Efforts are being made for extending the bytecode format with basic debug information (filename and line numbers).