Function constants

[Richard P. Gabriel <rpg@lucid.com>]

``No, this is a FUNCTION special form, not a function constant.  What
you are dumping and loading is code which will create a function
object when executed, not the function object itself.''

I know, but if you cannot dump anything like a function in any context,
you're really losing. (I don't believe in smiley faces, but there should
have been one there.)

``I agree this is the main question from an implementation point of
view.  I know that for some implementations (i.e., UCL), this
requirement would be a major headache.''

I'll challenge this. I think only KCL might not be able to do it.
Is UCL Utah Common Lisp? 

``I'd argue that since this isn't compatible with current practice....''

If no one can do it because it is too hard to implement, how can it be 
incompatible? You mean that it isn't part of current practice.

``I question whether the need for the ability to dump function
constants is really all that great.  I'm having a hard time even
coming up with a realistic example that could not also be handled
using LOAD-TIME-VALUE''

This is an interesting point. I actually almost never use constants
of any sort except for NIL and numbers. Maybe someone could make a
little list of the uses of constants aside from numbers and lists - 
maybe having anything but those around is worthless.

``We've already said that it's OK for function constants to appear in
code processed by COMPILE or EVAL -- issue QUOTE-SEMANTICS said that
constraints on what kinds of objects can appear in constants apply
only to COMPILE-FILE, and that COMPILE never copies.''

``I'd accept a statement that your second case is the only situation in
which function constants seen by COMPILE-FILE make sense, but saying
that's the only situation in which compilation with COMPILE-FILE is
meaningful seems like it's going way too far in the wrong direction.''

Well, here's an interesting point. I think it is important for our
specification of compiler semantics to be the same regardless of the
context - otherwise we are specifying too many languages. Already we
see arguements that COMPILE and COMPILE-FILE should be different.

I am trying to avoid a situation in which we go to great lengths to
define a language - Common Lisp - and then we turn around and say,
``heh, now if you want to write programs and compile them, here are
the rules: if you're going to compile things this way, you can do this,
but you can't do that; if you're going to compile things this other way,
here's what you have to do....''

The issue is to make sure there are at most two languages defined -

1. Common Lisp in Plato's heaven
2. Common Lisp that a compiler understands

I think having a restrictive set of scenarios in which any conforming
Common Lisp program is guaranteed to have the semantics described in
the specification is vastly better than a series of different
languages.  I think we have to be explicit in stating that these
restrictive scenarios are ones in which we cannot uniformly state what
every implementation can do uniformly, but that the intention is that
every implementation will try to make the same compilable language
work in all compilation scenarios, not just the ones laid out.

``Random people picking up the Common Lisp standard would get a very bad
impression of the language from seeing a restriction like that, and
it's certainly not consistent with current practice.''

I think they will like less the specification of a number of
languages.  And it is consistent, because it is a subset - again, you
mean it isn't the same as current practice. If you want to give the
best impression, then let's just say that there is Common Lisp, and
the compiler is allowed to copy or not allowed to copy in certain
situations, and that otherwise any compilation is
semantics-transparent - any implementation that doesn't provide this
is out of conformance.

			-rpg-