Three Uncommon Lisps - PDF document

Three Uncommon Lisps Julian Padget Bath, Bath, Avon, This paper surveys three Lisp systems populario. Nevertheless, each features which them particularly certain applications all exhibit certain as- their design which greater recognition. The three LisplVM (nee LispN70) Cambridge Lisp. the last inherits from both Standard Lisp porn compare the compromises in Cambridge Lisp versus is a second generation Lisp from The obvious to structure this paper, following from the abstract, Hearn [I9691 and revised and extended in Marti et al. [1979], Portable Standard grew out the 1979 operations defined the Standard Lisp report ' et al., 19821 PASS, 19871 a natural consequence. Between first Standard the second, it realised that making Standard a compatibility definition too inflexible that the constituted a systems. Subsequently various Standard Lisp (SLISP/360 based on Lisp for IBM1360 systems. the development been placed system dependencies compiler (first Griss and Hearn [I9811 later (but less successful) version described al. [1986]). emphasising that these areas where most has been expended is to a particular high-level language, Lisp itself as the system, Cambridge Lisp rigidly tied to calling and early stages beneficial, in perhaps questionable. The use BCPL has port Cambridge to other the process Portable Standard Lisp the first to port IBW370 and several design Cambridge Lisp reflect this physical which can make system to a machine which is not IBW370-like. Cambridge Lisp in mind, but (serendipitous) choice a high-level language for system has made this In many respects Cambridge Lisp a compromise LispIPortable (in which semantics are LispIVM has the upper hand, almost pitch & Norman, 19761 and pitch & Norman, 19771. 3. Semantics The relationship and the mathematical foundations lambda- somewhat loose, lately, Lisp implementations their logical roots. enshrined a lambda-calculus, albeit a useful misunderstanding and thus to its longevity. The principal issue under semantics is the names, which can and the resolving a reference. The preceding the question The matter names is not adherence to the true lambda calculus because it also ramifications for the efficiency of the lambda calculus [Sussman & Steele, 19751. Whilst lexical scoping permits of the binding, dynamic scoping more complex machinery for access to bindings. Although Lisp systems in the interpreter, lexical is preferred because it is more semantics are not the same differently after compilation, debugging, often inimical environment that provided but does not in LispIVM. described earlier, LispIVM is based SECD machine and compiled code is required the actions SECD machine same program (that is, compilation is a semantics preserving program at any time, a to behave differently from its interpreted counterpart, the compiler is correspond, rather the difference declared a feature. is a pay, in complex support required to compiled code those mechanisms engender costs in both There is still because Lisp permits macro when an expression is compiled. There is that such prevented without circumscribing the current nature macros under compilation is forcing binding of something that depends It is another issue such a second topic the opening paragraph has been the controversy. Early Lisps were ambivalent the value different from the value in an explicitly stated in the theory is clear that (x x[y:=x], Lisps, (Scheme, LispIVM, Cambridge Lisp, sought to maintain this consistency resolution whilst other Lisps preferred to maintain the ambiguity Each phase above increasingly frees the system (but not implementation) from a specific Thus because Lisp/VM has a fair proportion assembler, the task to take advantage of the addressing scheme on IBM1370 is not and retargetting LispIVM completely different architecture is almost straightforward to Cambridge Lisp from first one must port BCPL and second one must port the Lisp and, addition, because its IBM ancestry, changing Cambridge Lisp not to a high-byte tagging scheme would be trivial. That said is not a job for the inexperienced retarget Portable modifying it to use does require some Nevertheless, PSL to be the outset and the latest incarnation (version is quite manageable, that accumulated experience factored out almost every implementation specific The usability of a system to a certain extent, subjective, although provision features does allow simple comparisons. A rough guide to the usability of each of the systems in paper can looking at where the priorities lay the development each system. PSL was concerned consequence little effort is to preserve debugging purposes and although the interpreter will check types, compiled code will not. Thus, able to get a (partial) list the pending function calls on the stack; at worst, one simply get a protection violation invalid opcode whatever ensues... Cambridge Lisp takes much more care leave a trail information for the debugger to a stream function calls and arguments. Naturally generating information does impose some performance penalty. Cambridge Lisp is more careful about type and coupled with the debugging information available does provide a rather more secure environment LispIVM in a different league. a minor level, there very comprehensive information available about the state the computation error occurred. is perhaps paradoxical information is more helpful working on compiled code than when working on interpreted code! This is a slightly unfortunate feature SECD machine model for the interpreter, since the stack only contains information about the state the SECD machine and understanding the nature the error requires some understanding of the rules in the SECD machine. The more obvious debugging support in LispIVM is provided the HEVAL stepperldebugger LMikelsons, 19851 within the LispEdit interactive editing environment. HEVAL stack facility and multiple environments in LispIVM run the debugging control on branch with the program that is the the debugging operation another branch. HEVAL coupled LispEdit and the sophisticated indexed file mechanism (version management, automatic recompilation) make for a more supportive program development environment either of PSL Cambridge Lisp. is natural consider that latest systems embody the latest and ideas. Although that can the case, and certainly PSL offers some well-engineered ideas on portability and system organisation, some of the ideas that are only accepted now their genesis over 10 years ago. None of the systems presented here are Portable Standard Lisp LispIVM represent opposite ends of a specmm which puts portability and efficiency one pole and usability at the other. Cambridge Lisp could seen to represent a compromise position the choice use BCPL large part the implementation the loss LispIVM's lexical scoping several opportunities were lost. All these systems points to recommend them and the wider Lisp community would recognising the thought and care into the aspects Lisp system design each system