LISP AND SYMBOLIC COMPUTATION An International Journal c Kluwer Academic Publishers Manufactured in The Netherlands An overview of EuLisp JULIAN PADGET japmathsbathacuk University of Bath School of Mathematical Sciences Bath BA AY United Kingdom GREG NUYENS nuyensilogcom Ilog Inc Landings Drive Mountain View CA USA HARRY BRETTHAUER bretthauergmdde German National Research Centre for Computer Science GMD POBox W Sankt Augustin FRG Keywords Lisp mo dules concurrency ob jectoriented programming conditions re ection Abstract This pap er is an abstracted version of the EuLisp denition As such it emphasizes those parts of the language that we consider the most imp ortant or note worthy while we just mention without much detail the elements that are included for completeness This is reected in the structure of the pap er which describ es the mo dule scheme the ob ject system and supp ort for concurrent execution in the main part and consigns the ma jority of the datatyp es to an app endix Intro duction EuLisp is a dialect of Lisp and as such owes much to the great b o dy of work that has b een done on language design in the name of Lisp over the last thirty years The distinguishing features of EuLisp are i the integration of the classical Lisp typ e system and the ob ject system into a single class hierarchy ii the complementary abstraction facilities provided by the class and the mo dule mechanism iii supp ort for concurrent execution Here is a brief summary of the main features of the language Classes are rstclass ob jects The class structure integrates the prim itive classes describing fundamental datatyp es the predened classes and userdened classes Mo dules together with classes are the building blo cks of b oth the EuLisp language and of applications written in EuLisp The mo dule This work has b een supp orted by to o many organisations and programmes to name them individu al ly here although sp ecial mention should b e made of the Commission of the Europ ean Communities and Jean Omnes of DG XI I I Information technology directorate A complete list of acknowledgements app ears in Section PADGET NUYENS BRETTHAUER system exists to limit access to ob jects by name That is mo dules allow for hidden denitions Each mo dule denes a fresh empty lexical environment Multiple control threads can b e created in EuLisp and the concur rency mo del has b een designed to allow consistency across a wide range of architectures Access to shared data can b e controlled via lo cks semaphores Eventbased programming is supp orted through a generic waiting function Both functions and continuations are rstclass in EuLisp but the latter are not as general as in Scheme b ecause they can only b e used in the dynamic extent of their creation That implies they can only b e used once A condition mechanism which is fully integrated with b oth classes and threads allows for the denition of generic handlers and which supp orts b oth propagation of conditions and continuable handling Dynamically scop ed bindings can b e created in EuLisp but their use is restricted as in Scheme EuLisp enforces a strong distinc tion b etween lexical bindings and dynamic bindings by requiring the manipulation of the latter via sp ecial forms EuLisp do es not claim any particular Lisp dialect as its closest relative although parts of it were inuenced by features found in Common Lisp InterLISP LELISP LISPVM Scheme and T EuLisp b oth intro duces new ideas and takes from these Lisps It also extends or simplies their ideas as necessary But this is not the place for a detailed language comparison That can b e drawn from the rest of this text EuLisp breaks with LISP tradition in describing all its typ es in fact classes in terms of an ob ject system This is called The EuLisp Ob ject System or TELOS TELOS incorp orates elements of the Common Lisp Ob ject System CLOS Ob jVLisp Oaklisp MicroCeyx and MCS Language Structure The EuLisp denition comprises the following items Level comprises all the level functions macros and sp ecial forms which is this text minus App endix B The ob ject system can b e extended by userdened structure classes and generic functions Level extends level with the functions macros and sp ecial forms de ned in App endix B The ob ject system can b e extended by user AN OVERVIEW OF EuLisp dened classes and metaclasses The implementation of level is not necessarily written or writable as a conforming level program A level function is a generic function dened in this text to b e part of a conforming pro cessor for level A function dened in terms of level op erations is an example of a level application Much of the functionality of EuLisp is dened in terms of mo dules These mo dules might b e available and used at any level but certain mo dules are required at a given level Whenever a mo dule dep ends on the op erations available at a given level that dep endency will b e sp ecied EuLisplevel is provided by the mo dule eulisplevel This mo dule imp orts and reexp orts the mo dules sp ecied in Table Table Mo dules comprising eulisplevel Mo dule Sections character A collection A compare A condition convert A copy A doublefloat A elementaryfunctions A event fixedprecisioninteger A formattedio A function lock null A number A object pair A stream A string A symbol A syntax table A thread vector A PADGET NUYENS BRETTHAUER This denition is organized in three parts Sections describ es the core of level of EuLisp covering mo dules simple classes ob jects and generic functions threads conditions con trol forms and events These sections contain the information ab out EuLisp that characterizes the language App endix A describ es the additional classes required at level and the op erations dened on instances of those classes The app endix is organized by class in alphab etical order These sections contain in formation ab out the predened classes in EuLisp that are necessary to make the language usable but is not central to an appreciation of the language App endix B describ es the reective asp ects of the ob ject system and how to program the metaob ject proto col and some additional con trol forms Prior to these sections dene the scop e of the text and error denitions and typ ographical and layout conventions used in this text Scop e This text sp ecies the syntax and semantics of the computer programming language EuLisp by dening the requirements for a conforming EuLisp pro cessor and a conforming EuLisp program the textual representation of data and algorithms This text do es not sp ecify The size or complexity of a EuLisp program that will exceed the capacity of any sp ecic conguration or pro cessor nor the actions to b e taken when those limits are exceeded The minimal requirements of a conguration that is capable of sup p orting an implementation of a EuLisp pro cessor The metho d of preparation of a EuLisp program for execution or the metho d of activation of this EuLisp program once prepared The metho d of rep orting errors warnings or exceptions to the client of a EuLisp pro cessor The typ ographical representation of a EuLisp program for human reading AN OVERVIEW OF EuLisp The means to map mo dule names to the ling system or other ob ject storage system attached to the pro cessor To clarify certain instances of the use of English in this text the following denitions are provided must a verbal form used to intro duce a required prop erty All conforming pro cessors must satisfy the prop erty should A verbal form used to intro duce a strongly recommended prop erty Implementors of pro cessors are urged but not required to satisfy the prop erty Error Denitions Errors in the language describ ed in this denition fall into one of the fol lowing three classes dynamic error An error which is detected during the execution of a EuLisp program or which is a violation of the dened dynamic b ehaviour of EuLisp Dynamic errors have two classications Where a conforming processor is required to detect the erroneous sit uation or b ehaviour and rep ort it This is signied by the phrase an error is signal led The condition class to b e signalled is sp eci ed Signalling an error consists of identifying the condition class related to the error and allo cating an instance of it This instance is initialize d with information dep endent on the condition class A conforming EuLisp program can rely on the fact that this condition will b e signalled Where a conforming processor might or might not detect and rep ort up on the error This is signied by the phrase is an error A pro cessor should provide a mo de where such errors are detected and rep orted where p ossible environmental error An error which is detected by the conguration supp orting the EuLisp pro cessor The pro cessor must signal the corre sp onding dynamic error which is identied and handled as describ ed ab ove static error An error which is detected during the preparation of a Eu Lisp program for execution such as a violation of the syntax or static semantics of EuLisp by the program under preparation PADGET NUYENS BRETTHAUER NOTE The violation of the syntactic or static semantic requirements is not an error but an error might b e signalled by the program p erforming the analysis of the EuLisp program All errors sp ecied in this denition are dynamic unless explicitly stated otherwise Conventions This section denes the conventions employed in this text how denitions will b e laid out the typ eface to b e used the metalanguage used in de scriptions and the naming conventions App