Loose ends

[Scott E. Fahlman <Fahlman@CMU-CS-C>]

Just a couple of loose ends to tie up.  I am swapping out for a few days
and Guy may be in a position to finish up a draft of the manual before I
return, so I would like to just propose a couple of things that will go
in if nobody objects by the time he gets to them.  I think that these
proposals will be uncontroversial, but I've been wrong before on such
issues.

1. FLOAT-SIGNIFICAND and FLOAT-INTEGER-SIGNIFICAND are now confusing
names, given the change in semantics approved by the last ballot.
I propose that these be called DECODE-FLOAT and INTEGER-DECODE-FLOAT,
unless a better name is proposed within the next 24 hours or so.  I
propse that the determination of "better" will be done by Guy.

2. Whatever we call the functions listed above, it is proposed that they
return a third value which is the sign of the number, in the format
currently supplied by a one-arg call to FLOAT-SIGN.  The rationale is
similar to the rationale for combining the significand and the exponent:
whenever you want any of these, you almost always want all of them.  I
suggest that we leave it up to Guy to decide whether, given this change,
FLOAT-SIGN is useful enough to keep.

3. People have aksed for a clarification of the RECURSIVEP argument (I
guess given the hyphen rules, this should not be RECURSIVE-P after all)
to read and friends.  The following items are affected:

a. Top-level calls rebind the ## environment; recursive calls don't.
b. Top-level calls establish the preserve-whitespace flag; recursive
   calls observe this but don't change it.
c. Top-level calls establish the action to be taken if end-of-file is
   read.  I have no objection to Moon's suggestion that an error in a
   recursive read, if it is in the middle of an object, always signals
   an "eof in middle of object" error.  I am not sure whether a
   recursive call would ever have to handle an eof that would not want
   to cause such an error, but if so, the top-level eof switches should
   control the action.  A bit more thought is needed here to decide just
   how to state this.
d. In some implementations, a great deal of efficiency can be gained by
   checking certain things at top-level and not at every recursive call.
   (An example is pre-processing the stream into something lower-level
   for use within the call.)  The RECURSIVEP argument provides some
   necessary information for such decisions.

It would of course be possible to eliminate the RECURSIVEP argument and
to do the same thing with a special variable -- this is true of every
argument to every Lisp function.  If we do that, we would have to
document this variable so that error handlers and character macros that
want to establish a new top-level dialogue can rebind it to its
top-level value.  (That would be a rare occurrence, but one that we
ought to allow for.)  We could have gone this way, but the necessary
machinery is nearly identical, so I see no reason to re-open the
argument.  Let's stick with the RECURSIVEP argument.