Re: Issue: EVAL-WHEN-NON-TOP-LEVEL (Version 5)

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

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

I'm having trouble understanding what you are saying here.

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

I wasn't intending my :EXECUTE to be different from your :EXECUTE.  I'm
not sure if I just used a poor choice of words to describe it or if I've
missed some subtlety of your proposal.

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

This gets into the realm of style warnings, which is highly subjective.
It is unlikely that we would reach a consensus about the right way to do
this.  I don't foresee an occasion to use this situation myself, but I
included it for the sake of completeness, so as to not prevent someone
 from doing this if they wanted to.

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

I don't feel real comfortable with this either, but I was trying to
resolve the ambiguity about where the side-effects of compile-time
evaluation are supposed to occur.  Our implementation uses a heuristic
approach that does the reasonable thing most of the time, but there have
been complaints from customers who get unexpected results.  For example,
it is not obvious that (EVAL-WHEN (COMPILE) (DEFMACRO ...)) installs the
macro in the global resident environment, while (EVAL-WHEN (EVAL COMPILE
LOAD) (DEFMACRO ...)) just puts it in the compile-time environment.  It
seems like it would be better to provide a way for the programmer to
indicate what he wants, even if the implementation can't always comply
fully.

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

I think this is a case of the difference between conforming to the
specification versus being what the customer wanted.

>  * 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).

The fundamental difference here is that EVAL-WHEN is used to control
when side-effecting actions occur, while LOAD-TIME-VALUE is used to
produce a result value.  Consequently, the contexts in which they are
useful are different.