Issue: PLUS-ABNORMAL

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

Personally, I think it follows as a logical inductive consequence of the
description on p325 that this is already true. However, if someone
thinks it needs to be stated explicitly, that's fine.

The proposal is poorly worded in a few places because it talks about
the evaluation of + when it should refer to the evaluation of the 
`input expression' or some such.

(The proposal is possibly incomplete in that if you're going to specify
this, you might also want to specify the same thing for the variable -.
Within a use of #. the variable - is usually bound to the same as + . :-)

I wonder if it's a good idea to be so specific about all this though.
There are other gray areas that we might want to specify as well, and
we may quickly end up infringing on `the environment.' 

Other problems I've had with these variables are:

 - Some implementations do not update * and company when the result
   was generated by (VALUES).

   Symbolics does this. It's in violation of CLtL, but I happen to
   think that it's a good idea anyway since it can't break programs
   and since it's what makes it really useful to have DESCRIBE and
   PPRINT return that. Otherwise, they might as well return NIL.
   I really think CL made a mistake on this one.

 - Some debuggers do not maintain +, *, etc. while you're debugging,
   while others do.

   I think it's correct to make them available. When I used to use
   Vaxlisp, they were not made available, for example.

 - Some debuggers that make +, *, etc. available in the debugger
   do so by binding. Others continue to SETQ the same variables.

   I think continuing to SETQ the same variables is most useful,
   because it means you can still get back to the values you made
   in the debugger after you return.  However, I think others
   could legitimately disagree.

 - Of the debuggers which make +, *, etc. available by binding, not
   all initialize the values to the same values from the outer
   context.

   I happen to think that if you do it this way, the initial values
   should be the values of the `outer' variables.

This list is probably not exhaustive.

If any of these issues were to be raised, I think they should be raised
within the bounds of this proposal and not in a separate one, to
minimize paperwork.

I kind of think that if we want to do anything with +, ++, etc.  it may
be to say that they are reserved for the implementation to assign as it
sees fit, and to give only vague guidelines beyond that -- referring
people to the implementation's manual for specifics.

If further revisions of the proposal are submitted, the few occurrences
of {\tt ...} should be dropped as unnecessary.