[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue COMPILE-ENVIRONMENT-CONSISTENCY
- To: cl-compiler@sail.stanford.edu
- Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY
- From: masinter.pa@Xerox.COM
- Date: 5 Jan 89 21:27 PST
- Cc: masinter.pa@Xerox.COM
- In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of Tue, 3 Jan 89 15:24:49 MST
This proposal is written in the operational terms of what "a compiler" can
"wire in" or otherwise "assume". Is a program that only operates correctly
if the compiler doesn't "assume" these things legal? Conform to the
standard?
We've are defining the language in terms of what conformal programs will
do, and how conformal implementations will behave, almost completely
independent of the compile/interpret aspect -- rightfully so.
Most of the things that you say the "compile can assume" are in fact
constraints on valid programs.
For example
"The compiler may assume that functions that are defined and
declared INLINE in the compiletime environment will retain the same
definitions at runtime."
really means is that when calling a function that was originally defined
and declared INLINE but, at some later point in time, redefined, the
results are unspecified in that either the old (INLINE-proclaimed) or new
definition might be invoked.
I'm just worried about the process of going from this proposal to what
actually has to happen in the standard document.
We had considerable debate about 2b (I think on the common lisp mailing
list.) 2d is subsumed by cleanup LISP-SYMBOL-REDEFINITION, is it not?
2f means that you can't change a DEFCONSTANT, doesn't it?