Re: issue COMPILE-ENVIRONMENT-CONSISTENCY

[David N Gray <Gray@DSG.csc.ti.com>]

> Date: Fri, 2 Sep 88 15:18:53 MDT
> Issue:		COMPILE-ENVIRONMENT-CONSISTENCY
...
>   (This implies that SETF methods must also be available at
> 	compiletime.)

Should clarify that this refers to DEFSETF, not to (DEFMETHOD (SETF ...) ...)

> (2) The compiler *may* assume that, if any of the following kinds of
> information is present in the compiletime environment, the same information
> will also be present in the runtime environment. 

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.

>     (c) The compiler may assume that the signature of all built-in 
> 	Common Lisp functions will not change.

Is the term "signature" defined somewhere?

>     (e) Types that are defined with DEFTYPE or DEFSTRUCT can be assumed to
> 	retain the same definition in the runtime environment as in the
> 	compiletime environment.  (Note that it is not an error for an
> 	unknown type to appear in a declaration at compiletime, although
> 	it is reasonable for the compiler to emit a warning in such a
> 	case.)

Rather that "reasonable", I would say that it is "desirable" for the
compiler to emit a warning, since a declaration that references an unknown
type is quite useless and therefore must not have been what the programmer
intended.

> (3) The compiler *must not* make any additional assumptions about
> consistency between the compiletime and runtime environments.  In 
> particular:
>  
>     (a) The compiler may not assume that functions that are defined
> 	in the compiletime environment that have not been declared
> 	INLINE, other than built-in Common Lisp functions, will retain
> 	either the same definition or the same signature at runtime.
> 	It is, however, reasonable for the compiler to emit warning 
> 	messages about calls to functions that are defined in at
> 	compiletime, but where the wrong number or type of arguments
> 	are supplied.

This may be a little too strong.  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.

> 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.]

  -- David Gray