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

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

Only addressing part of your message for now...

    Date: Fri, 24 Feb 89  11:57:55 CST
    From: David N Gray <Gray@DSG.csc.ti.com>

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

LOAD and COMPILE have meaning only when in a non-top-level position.
EVAL has meaning only in a top-level position.

For any given context, if LOAD is `being considered,' then COMPILE is
`being considered' -- and vice versa.

For any given context, if LOAD and COMPILE are `being considered' then
EVAL is not `being considered' -- and vice versa.

In terms of fractions, if we think in terms of dividing up the work between
several EVAL-WHEN's, then

 (EVAL-WHEN (COMPILE)  50%-A)
 (EVAL-WHEN (LOAD)     50%-A)
 (EVAL-WHEN (EVAL)    100%-B)

expresses two different implementations of a problem. One for top-level, one
for embedded. Another common use is

    (EVAL-WHEN (COMPILE)   0%-A)
    (EVAL-WHEN (LOAD)    100%-A)
    (EVAL-WHEN (EVAL)    100%-B)

 or (EVAL-WHEN (EVAL LOAD) 100%-A/B)

 or just A/B

Both of these (the 50-50-100 and the 0-100-100) support the formula 
EVAL = LOAD + COMPILE. That is,

 100% =  50% + 50%
 100% = 100% +  0%

Now, we both know it may sometimes be the case that you have to write

 100% = 60% + 60%

because it's harder to break up the work in two pieces. This really just
says something about the fact that the `+' isn't exactly the right operator.
I still think, though, that the true operator is one with much the same
behavior as plus, so I think it's adequate to abuse `+' this way for the
sake of a simple rule of thumb.

Also, nothing keeps you from doing only half the equation. eg, you may be
willing to write something which only works interpreted, or you may want to
put in an error check to see that something only gets compiled. The equation
in those cases ends up looking like

     100% =   0% +   0%

  or   0% = 100% + 100%

Now even our funny `+' operator can tell that this equation doesn't balance.
Obviously it doesn't mean that you're doing something illegal, but it is at
least a nice intuitive hint that you are doing something `clever' (and `clever'
in my book is a synonym for `questionable' whenever it is used in a programming
context).

The mere fact that our version of the proposal makes it possible to 
distinguish `questionable' uses of EVAL-WHEN from `normal' uses is a virtue,
in my opinion.

Now, getting back to the original point that I replied to and that you were
confused by, if you eliminate EVAL and LOAD and you leave only EXECUTE in its
place, you get a confusing mess like

 Embedded	Top-Level

 EXECUTE   =    EXECUTE + COMPILE

... or at least I do. And I don't see what good I'm going to be able to 
derive from it. I also don't see how I'm going to be able to write code to
`complement' what the `COMPILE' phase does specially if I can't tell whether
or not the COMPILE phase has run. Note that the neat thing in our thing is 
you can tell from within an (EVAL-WHEN (COMPILE) ...) that any accompanying
(EVAL-WHEN (LOAD) ...) has run and that any accompanying (EVAL-WHEN (EVAL) ...)
has not run just by virtue of knowing that you yourself are running.