Re: issue COMPILE-ENVIRONMENT-CONSISTENCY

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

> Date: Wed, 7 Sep 88  12:16:24 CDT
> From: David N Gray <Gray@DSG.csc.ti.com>

> Should clarify that this [setf method] refers to DEFSETF, not to 
> (DEFMETHOD (SETF ...) ...)

As the language is currently defined, "setf method" does refer to things
created with DEFSETF, and there is no (DEFMETHOD (SETF ...)).  If this
changes, I suppose the editorial committee will decide upon some standard
terminology to differentiate between the two.

> I agree with Perdue's comments that the issue is that the runtime
> environment should not contradict the assumptions made at compile time,
> without necessarily requiring the information to be present in the runtime
> environment.  For example, I can visualize a run-time environment which
> does not include a compiler and therefore has no use for proclamations, in
> which case it is not meaningful to say that the information exists there.

The things listed in section (2) do not affect only things that may be
safely ignored at runtime.  For example, licensing the compiler to
make assumptions about the type structure remaining the same allows it
to do things like substitute the expansion of a DEFTYPE'd type for its
name in a call to a function like TYPEP.  However, the compiler may or
may not actually do this, and the only way to guarantee that your
program will not break is to require that the user make sure the type
is defined exactly the same way at runtime.

There is nothing here to prevent you from making your implementation
look for certain kinds of information only at compiletime, and
documenting this as an extra feature of your implementation.  On the
other hand, I think it would be unreasonable to require all
implementations to do this.

> Is the term "signature" defined somewhere?

I thought it's fairly standard terminology.  Some people use
"contract" instead to mean the same thing.

> We shouldn't rule out the possibility of
> cross-compiling for a restricted runtime environment that doesn't permit
> redefinition of functions, although that would not be the default behavior
> of the compiler.

It's already been proposed that a limited form of this (block
compilation) be allowed, since some implementations already do it.
However, I don't think that a Lisp that disallowed redefining
functions entirely would be able to legitimately call itself Common
Lisp (see p 67 of CLtL).  Again, there is nothing that prevents you
 from extending your implementation to have a mode where it does
disallow redefinition of functions; it's just that programs that rely
on such a feature are not portable Common Lisp programs.

> > Does anything need to be added to cover interaction between the compiler
> > and CLOS?
> 
> Maybe something like:  The compiler can assume that a class name defined
> by DEFCLASS will also be a class name at runtime, and that class will be
> an instance of the same metaclass.  There may be additional conformance
> requirements imposed by the metaclass, but there are none for
> STANDARD-CLASS.  [The metaclass has to match because it controls
> optimization of SLOT-VALUE.]

This sounds good to me, although I'm certainly no expert on CLOS.
Should we also try to address the issue of what (if anything) the
compiler can do to optimize method dispatching?

-Sandra
-------