draft of alternate proposal for EVAL-WHEN-NON-TOP-LEVEL

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Fri, 24 Feb 89 16:27:57 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    Here is a draft of an alternate EVAL-WHEN proposal.
    I am open to suggestions on this writeup.  If everybody else hates
    this and thinks that the the general direction here is totally wrong,
    I will shut up and go along with the GENERALIZE-EVAL proposal.  But I
    personally would like to see something like this included in the
    writeup we send out to X3J13 to vote on.

I know I'm not "everybody else," but I think the general direction here
is wrong.  Here's your rationale:
 
    Rationale:
  
      This behavior specified by this proposal is simple and easy to 
      understand, and extends the behavior of EVAL-WHEN usefully to 
      non-top-level situations.  It is largely compatible with the behavior
      of EVAL-WHEN specified in CLtL, except for the situation shown in
      example #6 above.  Some people find the nesting behavior of EVAL-WHEN
      specified in this proposal to be an improvement over that specified
      in CLtL.

      This gives a useful meaning to EVAL-WHEN that supports useful and
      predictable behavior if defining macros are used in a non-top-level
      situation.

It's true that this extends to non-top-level situations, but I don't
believe that is either simple or easy to understand, as compared with
what CLtL says (or the version 5 proposal by Pitman and Moon that
extends CLtL to non-top-level situations).  I suppose that is a matter
of taste, but here's a specific example: In CLtL, if you want to make
a top-level form do what it always does and also happen at compile
time, you wrap (eval-when (eval load compile) ...) around it.  That
works.  In this proposal, eval-when always makes its body non-top-level,
which means that it is impossible to make a top-level form do what
it always does, plus something else, by wrapping an eval-when around it.
To me that makes it complicated and hard to understand.  I also think
the new shielded/unshielded concept is obfuscation.

Aside from that, I am very leary about the idea of changing a part of
the language that works in a way that some people don't like, to work in
a different way that other people don't like, when the semantic issues
are sufficiently complicated and cloudy that nobody can predict the
repercussions of the change.  This just seems very dangerous.  I would
be the first to admit that CLtL's eval-when feature is not the most
beautiful and well-thought-out language feature to come down the pike.
It also has a remarkably badly chosen set of keywords, which I think
contributes to confusion in the discussion.  However, your proposed
alternative doesn't seem to be much better, and suffers from the
disadvantage of not having a user community with five years' experience.
I would much rather be offered the choice of keeping EVAL-WHEN
compatible or switching to something different and obviously correct.
But I think the choice here is between keeping EVAL-WHEN compatible and
switching to something that's just different.

However, here's my real problem with all this.  I'm trying to figure out
what the standard should say about the expansion of the CLOS
defining-form macros.  I know that they should be defined in terms of
EVAL-WHEN.  The continuing instability of EVAL-WHEN, and the large
amount of mail to plow through, is really interfering with my ability to
figure anything out.  That may well say more about me than about
EVAL-WHEN, but it's still a fact.  I wish I could force myself to ignore
everything you're doing and just use the CLtL definition of EVAL-WHEN
for now.