Anonymous user
Category:Sparkling: Difference between revisions
→Syntax and semantics
m (→Performance) |
|||
| (4 intermediate revisions by the same user not shown) | |||
Line 29:
A somewhat more complex (unnecessarily complex for this purpose) version demonstrates some more language elements:
<lang sparkling>
stdout.printf("%d characters written\n", numCharsWritten);
};
printMessage(helloWorldString);
Line 57:
* Number ("number"): either a signed integer (C's <tt>long</tt> type) or a double-precision floating-point number. The only type of implicit conversion in the language is between integers and floating-point numbers (if an arithmetic operator has an integer and a floating-point operand, it will treat both values as floating-point and it will produce a floating-point result as well.)
* String ("string"): a sequence of bytes, which is not necessarily a human-readable string (it can contain arbitrary binary data). When exposed through the C API, a terminating 0 byte is always appended to the end of string. It does not count against the length of the string object, but it makes standard C functions to operate on Sparkling strings easily.
* Array ("array"): Simple integer-indexed array. Arrays are mutable. Arrays are bounds-checked (an out-of-bounds access causes a runtime error).
* Hash tables ("hashmap"): Mutable associative container. The type of its keys and values can be of any type, but indexing by <tt>nil</tt> or by the floating-point <tt>NaN</tt> value is not permitted.
* Function ("function"): in Sparkling, functions are first-class values. They can be passed to functions as arguments and returned by functions. There is a literal syntax for creating - possibly unnamed - function objects. Sparkling has lexical closures, so functions capture variables (by value) from outer scopes. All functions are variadic; it is not an error to call a function with more or less arguments than the number of arguments it is defined with.
* User information objects ("userinfo"): in order to facilitate the creation of third-party extension libraries, Sparkling has a "joker" data type, the user info. User info objects have two subtypes: weak and strong. Weak user info values hold an arbitrary, unmanaged, generic C pointer (<tt>void *</tt>), while strong user info objects contain a managed, reference-counted Sparkling object of an user-defined "class". (The Sparkling API makes it possible for users to define their own classes -- memory-intensive built-in objects like strings and arrays already use this mechanism for managing memory.)
Line 76 ⟶ 77:
== The standard library ==
Similarly to
The currently available standard packages are:
* I/O routines (writing/reading to/from standard streams and files)
* String manipulation: searching for and creating substrings, creating formatted strings, etc.
* Array and associative array manipulation, including sorting, searching and functional-style list processing, such as <tt>map()</tt> and <tt>reduce()</tt>
* Floating-point, integral and complex mathematical functions
* Shell and environment access (including system date and time), and access to the Sparkling API itself (e. g. compiling to bytecode, stack traces, etc.)
== Implementation ==
Line 100 ⟶ 101:
== 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, or any language that supports C linkage and calling conventions), and they must follow a predefined signature, which makes it possible for the Sparkling virtual machine to call such a function.
<lang C>int native_ext_fn(SpnValue *retVal, int argc, SpnValue *argv, void *context);</lang>
Function arguments are passed in an array of Sparkling value (<tt>SpnValue</tt>) objects, and the return value of a function - as seen by a Sparkling script - should be moved into place using a pointer to another <tt>SpnValue</tt>. 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).
The use of compiled, platform-dependent, native dynamic libraries is a work in progress. It is desired that they be added to the library with support for conditional compilation, in the same way libreadline and libobjc is used by the engine. This would mean that on systems which support dynamic loading and expose a C API, users will be able to benefit from the use of pre-compiled libraries, meanwhile on platforms that do not support dynamic code loading, this feature would not impose an irresolvable dependency, so Sparkling could continue to run on those platforms as well, without the ability to load dynamic libraries.
== Debugging ==
| |||