hume@dover.uucp (Chris Hume) (01/06/89)
Thanks Barry, for the pointer to Genera's VARIABLE-xxx special forms and for the luminous BETTER-xxx example. There appears to be an information boundary here, where Common LISP implementations are not expected to make certain internal functions (like their equivalent of the VARIABLE-xxx special forms) available to portable code. Is there a clearly stated consensus on which such internal information should remain hidden from portable code? For example, is it intended that one could write a reasonably efficient Common LISP implementation (for a new machine architecture) entirely in Common LISP? Chris -- Christopher N. Hume Net: ...!sun!sunburn!dover!hume MOTOROLA, Inc. M/D: DOV05 2222 South Dobson Road Tel: (602) 994-6835 Mesa, AZ 85202 FAX: (602) 994-6895
barmar@think.COM (Barry Margolin) (01/09/89)
In article <632@dover.uucp> hume@dover.uucp (Chris Hume) writes: >Is there a clearly stated consensus on which such internal information >should remain hidden from portable code? Use of anything not in the Common Lisp spec (currently CLtL, eventually the ANSI CL spec) renders the program non-portable, so all such internal information is supposed to be hidden from portable code. They are often dependent upon low-level aspects of the particular implementation; for example, the VARIABLE-XXX special forms only make sense in an implementation that allows things other than special variables to be unbound. >For example, is it intended that one could write a reasonably efficient >Common LISP implementation (for a new machine architecture) entirely in >Common LISP? I think it's possible to write a "reasonably efficient" implementation in CL, but not necessarily an optimal one. For instance, an EVAL in CL would presumably include code like: (let ((results nil)) (dolist (arg (cdr form)) (push (eval arg) results)) (apply function (nreverse results))) This should produce reasonable code from any decent compiler. But the actual EVAL implementation in some implementations may use subprimitives to push the evaluated arguments directly onto the stack, instead of consing a list and calling APPLY. Or if the APPLY function normally performs type checking of the first argument, EVAL might call a lower-level primitive that doesn't do this. It would not be reasonable to add these subprimitives to the portable language. For example, an implementation that passes arguments in registers wouldn't be able to implement a subprimitive that pushes an argument onto the stack. Most implementations have subprimitives along these lines, but they are generally different in each. The language standard has to stop at some point, and CL tries to allow as much flexibility in implementation as possible. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar