[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue COMPILE-ENVIRONMENT-CONSISTENCY
- To: email@example.com, firstname.lastname@example.org
- Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY
- From: cperdue@Sun.COM (Cris Perdue)
- Date: Mon, 5 Sep 88 15:38:42 PDT
> Here is a draft of another proposal dealing with what the compiler may
> "wire in" to the code it is compiling.
> . . .
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