Revenge of the Ballot

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

Ballot B:

A few loose ends.  With luck, this will be the final ballot before the
manual is finalized for the first edition.  There may be a couple of
messages on single issues that pop up during final cleanup of the
manual, but this should be the last multi-issue submission.

Please reply by dawn, Tuesday morning.  I plan to collate the answers
later in the day on Tuesday.

---------------------------------------------------------------------------
B1. Proposed that we require both halves of a complex number to be of
the same type, either both rationals or both floats of the same type.
The COMPLEX function will accept numeric arguments of mixed type, but it
will do floating-point contagion of the usual sort (floats dominate
rationals, floats of greater precision dominate those of lesser) before
returning the complex number.

[ I am not really qualified to have an opinion on this.  It would make
the system easier to implement, easier to understand, and it would get
rid of an ugly exception or two.  On some hardware (the S-1, for
example) homogeneous-type complexes can be handled by the hardware,
while mixed types are more awkward.  Therefore, if none of the
mathematicians in the audience has a good reason NOT to do this, it
looks like a good move to me. ]
---------------------------------------------------------------------------
B2. Proposed that we adopt Alan Bawden's suggestion that we return a
complex number from functions like (sqrt -1), where we would otherwise
have to signal an error.  If not this, please indicate what you think we
should do.

[ Same comment as above.  If we're going to have complexes (and we are),
it seems wrong for (sqrt -1) not to return one. ]
---------------------------------------------------------------------------
B3. Now that we have decided to change from MULTIPLE-VALUE to
MULTIPLE-VALUE-SETQ, Moon says that we must have this form take
pairs of arguments like SETQ and PSETQ.  Yes or no?

[ I say no.  The format is completely different since there is a list of
N variables and one value-producing form.  I don't think anyone will
assume that it must take pairs of variables (variable-lists, really) and
values as SETQ does.  To add this would be MORE confusing, not less. ]
---------------------------------------------------------------------------
B4. Proposals by Robert Cassels to change FLOAT-SIGNIFICAND and friends.

[ These all look like good changes to me.  There were also a couple fo
suggested clarifications to the manual that Guy can deal with.  Vote on
each part separately if you need to. ]

B4a. Proposal: Remove FLOAT-EXPONENT and FLOAT-INTEGER-EXPONENT, and
return those numbers as the second values from FLOAT-SIGNIFICAND and
FLOAT-INTEGER-SIGNIFICAND.

This would serve to make these functions more similar to the division
functions, and emphasize the close relationship between the values.  It
also leads to slightly improved efficiency of implementation,
particularly on systems with unnormalized (or denormalized) numbers, and
those with "non-numeric" floating-point values [IEEE floating-point,
anyone?] which must be checked.  (I'm assuming that when one value is
wanted, the other is almost always wanted also.)

B4b: Proposal:  Add new functions FLOAT-DIGITS and FLOAT-PRECISION.

(FLOAT-DIGITS float) would return the number of (FLOAT-RADIX
float) digits used in the representation of a floating-point number.
(Including the "hidden bit", if any.)  For most implementations, this is
really a property of the type of float.

(FLOAT-PRECISION float) would return the number of significant
(float-radix float) digits present in float.

Implementation: For implementations using only normalized numbers, these
functions would be identical.  (- (FLOAT-DIGITS float) (FLOAT-PRECISION
float)) would reflect the degree of denormalization of float.

These functions are needed to simplify the movement of floating-point
numbers from one implementation to another.  They are also needed to
convert numbers from one base to another in a way which reflects the
precision (doesn't print bogus digits).  FLOAT-DIGITS could be
computed for most implementations by (- (FLOAT-EXPONENT 1.0)
(FLOAT-EXPONENT SINGLE-FLOAT-EPSILON)) or something like that.  But
making it a function seems cleaner than some sort of typecase.

B4c. Proposal: Require the result of FLOAT-INTEGER-SIGNIFICAND to
reflect the precision of the floating-point number.

Currently, FLOAT-INTEGER-SIGNIFICAND is only required to satisfy the
identity relating it to FLOAT-INTEGER-EXPONENT.  That allows the result
to be scaled by various powers of the radix, so long as the exponent is
adjusted appropriately.  So if @i[b] is (FLOAT-RADIX float) and @i[p] is
(FLOAT-PRECISION float), the result of (FLOAT-INTEGER-SIGNIFICAND float)
for non-zero float should be between (EXPT b p) (exclusive) and (EXPT b
(1- p)) (inclusive).
---------------------------------------------------------------------------
B5. We've stil got to settle the business of top-level vs. recursive
calls to READ and friends.  Having considered all of the mail that has
flown by on this, I re-propose the following:

All of the functions that now take EOF-ERRORP and EOF-VALUE arguments
(except for READ-BYTE and READ-BINARY-OBJECT) will take an additional
optional arg after EOF-VALUE.  This arg, RECURSIVE-P, should be NIL if
the function is called at the top level in a read, T otherwise.  It
defaults to NIL.  If this is non-null, the eof actions are controlled
not by the funciton's own controls, but by the top-level call.  Also,
only top-level calls rebind the ## environment, etc.

I was thrown for a bit of a loop by Eric Benson's suggestion that
read-macro functions have to know whether they are at top-level so that
they will know whether their own calls to read are recursive or
top-level.  That seemed to require some heavy-duty changes until I
realized that a macro-character function is always called within a READ,
so it always wants to the calls it makes to be recursive, unless perhaps
it is initiating some sort of top-level dialogue with the user instead
of gobbling down more of the stream in which the macro character was
read.  Of course, this assumes that you don't call random
character-macro functions directly, but that they only get called by the
reader.

[ I think this does it.  Propose alternatives if you want to, but also
please indicate whether you can live with this. ]
---------------------------------------------------------------------------
B6. Rename MERGE-PATHNAME-DEFAULTS to MERGE-PATHNAMES and eliminate the
default-type argument.  (This is obtained from the defaults.)

[ Suggested by the folks at Symbolics who have experience with these
things.  They claim that users get terribly confused if the default type
present in the DEFAULTS argument is not used.  Sounds good to me.]
---------------------------------------------------------------------------
B7. Propose that we add a new slot, CONVENTION, to the pathname
structure, and an optional CONVENTION argument to the PATHNAME and
TRUENAME functions.  This convention is used in parsing the argument, if
it is a string, and is recorded in the resulting pathname structure so
that the pathname can be turned back into a namestring in the same
format.  CONVENTION is a symbol, not a string; the collection of
meaningful convention symbols is implementation-dependent.
PARSE-NAMESTRING, which already has a convention argument, would be
brought into conformity with this.

The rule should be that the convention, if it is supplied, is used to
guide the parsing, and an error is signalled if the string is not legal
in this convention.  If the convention is not supplied, the system will
examine the string and attempt to deduce the convention in some grossly
implementation-specific or site-specific way, perhaps by recognizing the
host name and looking up that host's convention in a table.  We should
not specify anything about how this is done; in particular, do not
specify that the host is delimited by "::".

The point is that the current proposal (a simplified subset of the
existing Lispm pathname facility) muddles together the notion of HOST
(the machine or network node where the file resides) and CONVENTION
(what file-naming convention is used in this file name).  A host might
be "CMUC"; its convention might be "TOPS-20".  A convention runs on many
hosts, and it is quite possible that some hosts will provide more than
one convention.  (Our 3600's may one day have a band full of
Symbolics-format files and a band full of Spice-format files, coexisting
happily; there are other examples around.)  In any event, code can be
more portable if it can deal with something as a Tops-20 filename than
as "whatever CMUC is".  Many places in the pathname section refer to
some feature as "host-dependent", when in fact it depends on the
convention.

[ I'm in favor. ]