Extensible Embeddable Language
Paradigm | Multi-paradigm: scripting, imperative, functional, object-oriented |
---|---|
Designed by | David Olofson |
First appeared | 2005 |
Stable release | 0.1.14 / November 22, 2009 |
Typing discipline | Dynamic |
OS | Cross-platform |
License | GNU Lesser General Public License |
Filename extensions | eel |
Website | http://eel.olofson.net |
Influenced by | |
Lua, C, Pascal |
The Extensible Embeddable Language (EEL) is a scripting and programming language in development by David Olofson. EEL is intended for scripting in real time systems with cycle rates in the kHz range, such as musical synthesizers and industrial control systems, but also aspires to be usable as a platform independent general purpose programming language.
Philosophy
As to the language design, the general idea is to strike a practical balance between power, ease of use and safety. The intention is to help avoiding many typical programming mistakes without resorting to overly wordy syntax or restricted functionality.
History
The first incarnation of EEL was in the form of a simple parser for structured audio definitions, used in the sound engine of the Free/Open Source game Kobo Deluxe, an SDL port of the X11 game XKobo. This was a simple interpreter with very limited flow control, and a syntax that's quite different from that of current versions. This initial branch of EEL was first released in 2002, and is still used in Kobo Deluxe as of version 0.5.1.
In December 2003, EEL was split off into a stand-alone project and subject to a major rewrite, in order to be used for real time scripting in an embedded rheology application. This is where the switch from interpreter to compiler/VM was made, and the actual programming language EEL materialized. The first official release was in January 2005. Since then, EEL has evolved slowly, driven mostly by the personal and professional needs of its author.
Features
General
The language is not strictly designed for any particular programming paradigm, but supports object oriented programming, or more specifically, prototype-based programming, through a minimal set of syntax sugar features. Other paradigms, such as functional, modular and metaprogramming are also supported.
As a result of avoiding pointers and providing fully managed structured data types, EEL is "safe" in the sense that EEL programs should not be able to crash the virtual machine or the host application.
Highlights
- C-like syntax.
- Opaque references (as opposed to raw pointers).
- Dynamic typing.
- Automatic memory management.
- Exception handling.
- Built-in structured data types, such as:
- string - immutable string.
- dstring - dynamic string.
- vector - fixed type numeric array.
- array - array of dynamically typed elements.
- table - associative array.
Example code
The classic hello world program can be written as follows:
export function main<args> { print("Hello, world!\n"); return 0; }
The following is an example of a recursive function:
export function main<args> { print("Recursion test 1:\n"); procedure recurse(arg) { print("arg = ", arg, "\n"); if arg recurse(arg - 1); } recurse(10); print("Recursion test 2; Mutual Recursion:\n"); procedure mrecurse2(arg); procedure mrecurse1(arg) { print("arg = ", arg, "\n"); if arg mrecurse2(arg); } procedure mrecurse2(arg) { mrecurse1(arg - 1); }; mrecurse1(10); print("Recursion test 2; Mutual Recursion with Function Reference:\n"); procedure mrrecurse1(arg, fn) { print("arg = ", arg, "\n"); if arg fn(arg, fn); } local mrr2 = procedure (arg, fn) { mrrecurse1(arg - 1, fn); }; mrrecurse1(10, mrr2); print(Recursion tests done.\n); return 0; }
Internals
EEL source code is compiled into bytecode for a custom VM, which has a relatively high level instruction set designed to minimize instruction count and thus overhead. The EEL VM is register based and "stackless", as in not relying on the C call stack for managing VM contexts.
The basic memory management method is reference counting, which allows automatic memory management with deterministic timing, without the need for concurrent garbage collection.
The VM uses "limbo lists" to keep track of intermediate objects created inside expressions and the like, which greatly simplifies exception handling, and eliminates the need for active reference counting in every single operation.