[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: EVAL-WHEN-NON-TOP-LEVEL (Version 5)
- To: Gray@DSG.csc.ti.com
- Subject: Re: Issue: EVAL-WHEN-NON-TOP-LEVEL (Version 5)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 23 Feb 89 19:42 EST
- Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Compiler@SAIL.Stanford.EDU, Moon@STONY-BROOK.SCRC.Symbolics.COM
- In-reply-to: <2813267244-7521051@Kelvin>
Thanks for taking the time to look this over. I have a few comments on your
proposed list of alternate keywords...
* Pursuant to the discussion I had with Moon prior to drafting version 5,
one way to look at my model is simply:
EVAL = COMPILE + LOAD
Either the left side of the equation is run, or the right side.
There are of course interesting cases where you don't implement one side
or the other of the equation, with some particular purpose in mind. Those
are ok with me as long as they follow from the design, rather than drive
Using this rule, you can do easy `proofs' to see that you've correctly
implemented all the relevant combinations.
By unifying EVAL and LOAD as simply :EXECUTE in your revised list, you've
destroy an important property of my keywords because you rob me of the
ability to distinguish the `execute' which goes along with not-COMPILE case
from the `execute' which goes along with the COMPILE case.
If you want to provide a `total' :EXECUTE, you must still provide
at least :EXECUTE-NON-TOP-LEVEL, :COMPILE-TOP-LEVEL, and :LOAD-TOP-LEVEL.
Pick whatever names you like, but that level of distinction is extremely
* As for :COMPILE-ALWAYS, an example might help. But I think you've isolated
a potentially `real' point of disagreement on goal (vs solution, which we've
been mostly discussing) when you say
``... This would be less common, but could still be useful for things
like noticing that a definition of a function exists in order to
suppress warnings about calls to an undefined function. ...''
I very strongly believe not only that this should not be a goal, but
that it should be a goal to prohibit the compiler from being allowed to
take such action.
If I have a function that is going to reliably define another function
and the compiler doesn't notice it, what I want is a way to declare
(i.e. proclaim) to the compiler that I promise to deliver that function
in time. What I do -not- want is for the compiler to not warn me in the
absence of such a declaration. It might be that I really didn't
realize that the thing would never get executed -- the compiler does
me no favors by failing to alert me to this potential problem in the
absence of the aforementioned proclamation.
If you think otherwise, then the problem is more serious than I was
assuming because we don't even have the same abstract goals in mind.
* As for :COMPILE-PERMANENT, I could not convince myself that it would not
be invasive to proprietary models of CL. What if someone really implements
a compiler such that COMPILE-FILE of a file that creates package FOO
does not leave package FOO present. It's my impression that what KCL
does amounts to this by running the file compiler in a separate
environment, but I can imagine totally different implementations
that achieve the same effect.
* Re: ``The primary reason that person 1 used EVAL-WHEN was that they wanted
it to happen at compile time; considerations of top-level-ness is a
secondary detail. Person 2 also wants it to happen at compile time.
So this appears to be a case of two rights make a wrong.''
This interpretation is nonsensical to me. If we documented EVAL-WHEN as in
v5, no one who understands what EVAL-WHEN does could have been party to
such a scenario as you describe. You either believe in the whole definition
of a primitive or you don't use it.
You wouldn't realistically expect me to give credence to a claim that SETQ
is buggy just because someone does
(DEFUN FOO () (SETQ *FOO* 3) (BAR))
(DEFUN FOO () (LET ((*FOO* 3)) (BAR)))
just because he thought the issue of global side-effect was `secondary'
If we adopt the v5 semantics of EVAL-WHEN, there can't be a presentation in
the documentation of `primary reasons' and `secondary reasons.' All you can
do is to present the semantics. Hopefully you suggest an intuition (such as
I did at the start of this message) but that intuition should not hide the
full semantics of the operation.
* Re: ``... controlling the time of execution is what EVAL-WHEN is
supposed to be for, so it seems odd that it works in some cases
but not others.''
I think this should not really be seen as an oddity. It doesn't do the job
of LOAD-TIME-VALUE. Does that seem odd to you? It used to seem odd to me,
but I've changed my opinion. I think that the two primitives do very
different things (yet they both control time of execution).
It also -- quite reasonably -- doesn't (and in fact, can't) do the job of #. .
In a strict philosophical sense, all of programming is really just about
changing the time at which execution occurs. Maybe you just need a new intuition
about what EVAL-WHEN does (or EVAL-WHEN needs a new name :-).