Re: issue COMPILE-ENVIRONMENT-CONSISTENCY

[cperdue@Sun.COM (Cris Perdue)]

> Here is a draft of another proposal dealing with what the compiler may
> "wire in" to the code it is compiling.
> . . . 
> -Sandra

The items under (1) make sense to me.

> (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.  In all of these cases,
> the absence of the information at compiletime is not an error, but its
> presence may enable the compiler to do a better job.

For me, discussing the subject in terms of permitting the compiler
to "wire in" ("bind names", etc.) information makes more sense and
is less restrictive than permitting the ocmpiler to assume that the
same "information" will be present at runtime.

(a) and (b) relate to compile-time binding of names, and in my view
    should authorize the compiler to use the known inline definitions
    and make "direct" self-calls rather than allowing it to assume that
    the same definitions exist at runtime.  (The former point of view
    seems directly relevant to the issues and appears to meet our needs.)

(c) authorizes the compiler to make assumptions about built-in functions
and to bind the CLtL definitions at compiletime.  (This seems to address
the relevant issue directly.)

(d) relates to compile-time binding of (constant) names.  I think we want
    to license the compiler to "wire in" the compile-time values, which
    doesn't absolutely require consistency.

(e) authorizes the compiler to make assumptions.

(f) authorizes the compiler to make assumptions, but it makes more
    sense in my view to assume *validity* of assumptions made at
    compile time rather than consistency with declarations existing
    at runtime.