Anonymous user
Category:Sparkling: Difference between revisions
→Syntax and semantics
| (12 intermediate revisions by the same user not shown) | |||
Line 13:
== 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.
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 implementation is currently hosted on GitHub, at H2CO3/Sparkling[http://github.com/H2CO3/Sparkling].▼
▲The reference implementation is currently hosted on GitHub, at H2CO3/Sparkling[http://github.com/H2CO3/Sparkling].
== Syntax and semantics ==
Line 27 ⟶ 29:
A somewhat more complex (unnecessarily complex for this purpose) version demonstrates some more language elements:
<lang sparkling>
let numCharsWritten = printf("%s\n", msg);
};▼
▲}
printMessage(helloWorldString);
Line 47 ⟶ 48:
$
</pre>
=== Fundamental language features ===
==== Types ====
Sparkling is a dynamically but strictly typed language. Typically, binary operators operate on values of the same type only, which is enforced by runtime checks. Standard library functions type-check their arguments as well. There are 7 types in the language:
* Nil ("nil"): the empty value. It has only one possible value: <tt>nil</tt>. It indicates the absence of any other meaningful value. It is the result of array indexing by a key that is not found, the return value of functions that don't return anything explicitly, the default initial value of local variables, and the value of missing function arguments.
* Boolean ("bool"): Sparkling has a proper Boolean (true/false) type. Conditions of the if statement and loops and logical operators require their condition to evaluate to a Boolean value (otherwise, a runtime error is raised -- there are no implicit conversions to Booleans).
* 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.)
Being a rudimentary feature of reflection, Sparkling supports querying the type of an object at runtime, using the <tt>typeof</tt> operator.
==== Variables ====
==== Expressions ====
==== Statements ====
==== Functions ====
A full language tutorial is available in the official documentation[https://github.com/H2CO3/Sparkling/blob/master/doc/tutorial.md].
Line 52 ⟶ 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 72 ⟶ 97:
== Performance ==
The reference implementation, being an interpreted language, doesn't have
== 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 ==
Apart from the already mentioned disassembler, the virtual machine provides a basic stack tracing feature, which can be accessed using the C API and, through a standard library function called <tt>backtrace</tt>, from a Sparkling program itself. Efforts are being made
| |||