Xerox Common Lisp development group meeting notes 3/4/86 The first tech meeting centered on a discussion of remaining issues from the Common Lisp book. A few global comments were made, including a decision not to go with Common LOOPS to implement Common Lisp, given that the standard is not yet accepted and the implemenation availble in Interlisp-D is still experimental in nature. It was noted that possible performance impacts will arise from deep binding globals like *ibase* and *package*. Lexical scoping was decribed as requiring more design before it could be presented. The existing type system implementation in CML was said to require scrutiny to discover its weaknesses. It does not implement SUBTYPEP, for instance. Andy Daniels was assigned this task. Program structure, performance of function call and ampersand rest and keyword arguments to functions, anonymous fns and closures. These were all mentioned and an uneasy consensus was reached that the, possibly slight, performance loss of the current scheme would have to be accepted in order to keep resources free for the rest of the implementation effort. Anonymous fns and closures were mentioned as issues to be resolved by Larry and Bill at some point. Predicates, especially the possible performance issues in the current implementations, were given to Bob Bane to examine. Control structure as an area was broken down into the interaction of special forms with the interpreter, this issue was deferred to the compiler and interpreter group. SETF was given to Bob Bane to examine. The CALL-ARGUMENT-LIMIT was described as untested and possibly too small. Multiple values have been implemented by Larry in a somewhat low performance manner, but one that has gone together quickly. The evaluator, and its handling of special forms, was discussed. The possibilty of having two evaluators, an additional one for CL, triggered by CL:LAMBDA, was mentioned. Gregor brought up that Symbolics had used a similar scheme up until their current release and that it produced the obvious confusions. Three possibilities were summarized: 1) Port the Spice Lisp interpreter, presuming that its mechanism for handling special forms and lexical environments would answer our needs. Primary difficulty is maintaining an understanding the behavior of two intepreters. 2) The Interlisp interpreter could be extended to handle lexical environments and special forms. 3) Run all code compiled. This simplifies the interface between compiled and interpreted code and gives us a single set of code to maintain (no parallel development of interpreter code). The consensus seemed to be that this issue should be further dealt with by a small group in concert with the lexical binding designer (Bill). ( ?1(DEFAULTFONT 1 (GACHA 10) (GACHA 8) (TERMINAL 8)) 9¸T½hdz™Aò%âa¼Ž Æzº