Gamma (and the SCADALisp engine) has these features and attributes:
User-definable functions: A developer may define functions with any number of arguments, including the ability to specify arguments as optional, unevaluated, and variable count.
Local variables: Variables may be defined as local to a block of code. Function arguments are automatically declared local.
Dynamic scoping: Variable scopes are dynamic, so that a function may temporarily override the value of a global variable, and that override will carry into sub-functions.
Garbage collection: Unused memory is collected and re-used whenever appropriate, relieving the developer of responsibility for memory management. The garbage collector typically runs in less than 0.05 seconds on an Intel 486/33 computer.
Data abstraction: Gamma data items can be of any of the following types: integer, real, string, symbol, list, array, buffer, function, class, instance. Gamma variables may take on any data type at any time, and change types during program execution.
Recursion: Gamma functions may call themselves with different arguments.
Object-oriented programming: Gamma contains support for a single-inheritance object-oriented paradigm, including instance variables and virtual methods. Constructors and destructors are triggered for all ancestors of a class. Methods are overloaded. C structures can be mapped to Gamma classes.
Error handling: Fatal errors may be trapped, causing the Gamma engine to enter a debugging mode, or errors may be trapped non-interactively allowing execution to continue from a user-defined safe recovery point. Blocks of code may be protected such that they will be executed even if an error occurs in preceding code.
Real-time timers: Gamma functions may be run on a timed basis, independently of other running functions. The timers can be made to pre-empt any function except the garbage collector, and will run within 0.5 msec of the desired time except where limited by the operating system or the garbage collector. The practical timer resolution depends on the system clock, though times may be specified in nanoseconds. Three types of timers are provided: interval timers, one-shot relative timers, and date-related interval timers. Interval timers will not drift, even if momentarily delayed by garbage collection or operating system delays (such as task switching). If a timer is delayed, subsequent firings of the timer will "catch up" the time of the previous delay. Over a long time period, an interval timer is guaranteed to fire (time period) / (interval) times. Date-related timers allow the user to specify an interval or one-shot timer which will fire on a particular day of the month, month of the year, year, hour of the day, minute of the hour, and second of the minute. Any of these may be a list of options, allowing, for example, a timer to be set which will fire at 3:00 am every 1st and 15th day of every January, April and October. A timer can trigger any Gamma function, including a user-defined function or a code fragment.
Signal handlers: Gamma can execute any command whenever a signal occurs. This makes it possible to recover from floating point errors, segmentation faults and out-of-memory errors. This also allows a program to react to or ignore interrupt signals.
Inter-process communication: Gamma implements most of the QNX inter-process communication functions, along with a system-independent synchronous/asynchronous communication mechanism based on QNX's send/receive/reply mechanism. This mechanism enforces some limitations on multi-task systems, which are generally consistent with the goals of control systems. These are:
A task may only have a single asynchronous input queue.
A task must initialize the inter-process communication system early in its run cycle, and may not initialize this more than once.
Run-time debugging: Gamma programs can be altered on-line as they run without being shut down. A bump-less transfer mechanism allows updates to the Gamma program at any time. The current state of the program and individual variables can be queried and altered as the program runs, allowing a developer to diagnose problems on the running system by modem or over a network.
Attachment to a datahub: Gamma has built-in facilities to deal with the Cascade DataHub, including the ability to accept unsolicited value changes (exceptions) from the datahub.
Confidence factors: All data items have an associated confidence factor. Confidence factors are modified through assignment and mathematical operations. This allows Gamma programs to take confidence factor into account when implementing control. System start-up transients can be avoided if control strategies ignore variables whose confidence is too low to generate reliable control operations.
Support for the Photon Widget Set: Gamma supports all of the Photon widget set, including most of the "Pt" function calls for widget manipulation. Cogent will track changes to the Photon API as new Photon versions appear. Gamma can read and display windows and dialog boxes created in the Photon Application Builder.
Support for 90% of QNX Windows function calls: Most QNX Windows function calls are supported, either by directly mappings function arguments or by modifying the argument lists while retaining the intent of the function. Functions dealing with local memory buffers are typically not implemented. Event functions are limited to common event types, and are generally only accessible through the generalized event handling mechanism, rather than through QNX Windows calls.
Small running size: Typical Lisp implementations require 2 to 6 Mbytes of RAM to run. Gamma runs in about 250 Kbytes without windowing support and approximately 600 Kbytes with windowing support. Embedding Gamma into another process adds about 100 Kbytes on disk, and about 170 Kbytes when running.
Embeddable: Gamma can be obtained as an object library that can be linked with any user program to provide an embedded macro language including all functions of the Gamma engine.
C-language extensible: C-language functions may be added to the Gamma language. This requires re-linking the Gamma executable, and the addition of a new function "package".
Loadable grammars: Gamma is itself an example of an alternate grammar used to program the SCADALisp engine. It is also possible to replace the SCADALisp writer, to allow expressions to be written in other languages, but this is not necessary in order to implement an alternate grammar. Replacement of the Gamma grammar requires modification of the Gamma engine mainline. The SCADALisp engine can always read Lisp code, even if an alternate grammar is being used.
Portability: Gamma has been ported to QNX 4.2 in 16 and 32-bit models, SCO UNIX and Linux. Other UNIX ports should be possible.