Some questions

[Rob MacLachlan <RAM@>]

    Date: Friday, 30 May 1986  00:21-EDT
    From: miller.pa at Xerox.COM
    To:   Common-lisp at SU-AI.ARPA
    Re:   Some questions

    	Now that all you people and companies out there are doing all these
    common-lisp compilers, I'd like to ask you some questions:

    Do you transform the source to continuation passing style before
    compiling?  
    How happy are you with this decision?  
    If you don't, do you do tail-recursion optimizations anyway?
    If you do, do you do multiple values by calling the continuation with
    multiple arguments? 

The current Spice Lisp compiler is basically a one-pass compiler which
goes directly from s-expressions to lap code.  Closure variables are
implemented by patching the lap code when a reference is a closure is
discovered.  The compiler is not tail-recursive, but tail-recursive
self-calls turn into branches.  Support for Common Lisp features not
in Maclisp is generally poor.

Many of the Common Lisps floating around are based on Spice Lisp and
this compiler.  Some exceptions are Symbolics, Lucid and KCL.  The
Lucid compiler was originally based on the S1 compiler, but has
reportedly been largely rewritten.  The Lucid compiler is probably
close to state of the art, but they are unlikely to talk about it in
public.

I am currently writing a new compiler for Spice Lisp which is designed
for Common Lisp and designed for portability.  It will be
tail-recursive, but I am not using CPS per se.  The internal
representation is not a syntax tree at all, but a flow-graph like
representation optimized for flow analysis.  The idea is that most
analysis and optimization will be done using flow analysis rather than
tree walks.  It is too early to tell whether this is a good idea.

    Should the parameter list in a multiple-value-bind allow :optional,
    :rest, etc...
What level is this question at?  CLTL clearly doesn't allow any of the
lambda-list keywords in the variable list for multiple-value-bind, but
if you just macroexpand multiple-value-bind to a multiple-value-call
of a lambda, then it isn't very hard to do.

    	When the silver book says that something has dynamic extent, it is
    allowed for an implementation to provide indefinite extent, since "it is
    [only] an error" to try to interact with a value whose extent has
    expired.  Providing indefinite extent would be a clean way for an
    implementation to offer upwards compatible extensions of the language.
    This would be particularly useful for catch tags.
It is meaningless to talk about extending Common Lisp CATCH to have
indefinite extent, since it has dynamic scope.  Extending
BLOCK/RETURN-FROM is a possibility, but I doubt that there's a great
deal of enthusiasm.

    How happy are you with packages?
    In particular, for those familiar T's reified lexical environments (aka
    LOCALEs), can you think of any reason for preferring packages?
Packages cause a lot of grief, especially for new users.  I think that
schemes like locales that separate values from names are cleaner, but
the historical compatibility imperative for Common Lisp probably makes
such schemes impossible.  This is because the dialects with which
compatibility was desired have always confused names and values.  In
any case, it is clearly too late to replace packages with anything
very different.

    Can the global scoping environment consistently be considered to simply
    be the outermost lexical environment?
This question doesn't make a great deal of sense in Common Lisp, since
it isn't block-structured.  Some operations always manipulate the
global environment (DEFUN), others create local definitions (LET).
You can define some things globally which you can't define locally,
(types, constants), so the answer to you question may be no.

    Can T's LOCALEs be added to the language in an upwards compatible way?
What do you mean by upward compatible?  It would certainly be pretty
gruesome using two namespace management systems simultaneously.  The
separate function, value and property-list cells would certainly hair
up any LOCALE-like scheme.

    Has anybody given any thought to defining a formal semantics for
    common-lisp?
    Do you think there is any hope for such a thing?
We don't even have an informal definition yet...

  Rob