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

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

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

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

 * 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))
   rather than
    (DEFUN FOO () (LET ((*FOO* 3)) (BAR)))
   just because he thought the issue of global side-effect was `secondary'
   do you?

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