One of the reasons for Lisp's longevity is the (surprisingly rare) identity of code and data. A Lisp data item can be interpreted as a piece of Lisp code, allowing programs to build up and pass around pieces of code as data values. Hence the applicability of Lisp in artificial intelligence. The 'code-as-data' identity in Lisp has shown itself to be exceptionally valuable in event-driven systems where a user generally wishes to attach an arbitrary piece of code to any event, without regard to how that event is delivered. This approach has been used with tremendous success in programs like AutoCAD and Emacs, which treat mouse actions and keystrokes as events.
Powerful windowing systems such as QNX's Photon and X-Windows use callback functions when an event occurs. It is of great benefit to a programmer to be able to attach an arbitrary code fragment to a callback. Unfortunately, C language interfaces for systems such as these require functions with pre-defined arguments to be compiled into the code, limiting the run-time extensibility of the resulting program.
Gamma, on the other hand, inherits Lisp's ability to express code as data, enhancing the Photon callback mechanism and making it trivial to attach code to user interface events. Gamma also inherits speed optimizations from SCADALisp, making its performance comparable to compiled Lisp implementations such as GNU's GCL.
"Simple things should be simple. Difficult things should be possible." This is the hallmark of any good computer programming language. If it is hard to do a simple thing, then the language is poorly designed. If it is impossible to do perform a difficult task, then the language is under-powered. The C language got this half right. Difficult things are possible. Anybody who has tried to read in a list of words from a file, store them in memory, sort them, and process them in sorted order (a relatively simple task to describe), knows the annoyance of memory management, resizing arrays, maintaining counters and pointers, and trying to work out exactly how many levels of de-reference we need for a qsort call.
In Gamma, this operation is quite literally 15 lines of code. Control flow problems and the majority of data manipulation tasks can be handled with far less effort and development time in Gamma. This, combined with interactive coding and debugging, makes Gamma a far better development environment for a wide range of tasks. This is particularly true for one-time code, which is typical of custom control applications.
The trend in commercial programs has been toward embedded languages of one sort or another. Graphical interface tools such as HyperCard and Toolbook were seen as great leaps forward due to their use of an embedded language with special-purpose features to provide previously unimagined versatility. AutoCAD ships with AutoLisp, making it the clear winner when it comes to the ability to customize the application, and the undisputed leader in PC-based CAD packages. Microsoft Word® and MS-Excel® embed Visual Basic®, allowing the user to define complex macros that include support for a wide variety of windowing objects (known as widgets). All commercial modem communication packages, such as ProComm Plus, contain a script language. It is doubtful whether serious entries into many of these product areas would sell without an embedded script language.
The SCADALisp engine has already been successfully embedded into an event-driven remote modem communications package for process control, and was embedded into a graphical 'shoot-em-up' adventure game called "Abuse" (unfortunately, for business reasons, the SCADALisp engine was replaced by a slower and less complete Lisp interpreter).
Gamma is currently shipping as part of Intel s Internet Appliance Toolkit, designed to highlight the ease with which Internet appliances can be created using Intel processors, QNX, and Gamma.
Using an embedded script language provides extensibility and customization. But invariably these languages are particular to the application, containing special constructs designed to make scripts relevant to a program easier to write. This generally means that a word processor cannot talk to a spreadsheet which cannot talk to a communications package which cannot talk to a database, and so on. There may be compelling reasons why a spreadsheet needs a different language from a word processor, but by using the same Lisp execution engine for both programs, application-specific script languages can be embedded into any user program, while still allowing these programs to communicate with one another using the underlying Lisp language. This provides a level of co-operation not found even in systems such as OLE or CORBA. Historically the only system to attempt this level of interaction is REXX, though even here user programs generally provide only the simplest of parsers.
SCADALisp is constructed as an embeddable API library, with hooks to allow any YACC grammar to be used in conjunction with the normal Lisp grammar. Window system calls and QNX inter-process communication services are built into the language, allowing any program to immediately implement a full-featured script language and communication facility.
Many applications require a graphical user interface as a semi-independent facility, where any program can transmit a simple request to the GUI screen to change values, colors, etc. A user interface built in Gamma, combined with the inter-task co-operation mentioned above, provides a means for any program to send a simple text command to a Gamma user interface to alter the screen in ways limited only by the GUI implementation. In a matter of moments a program can take advantage of the native GUI without the overhead imposed by linking to the GUI API. This type of architecture is particularly inviting in multi-tasking environments such as QNX.
Gamma has been used in process control applications to provide user interface features to control systems where off-the-shelf interface products could not provide the level of connectivity and functionality required.