Results of ballot B

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

Results of Ballot B:
---------------------------------------------------------------------------
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:
APPROVED.
---------------------------------------------------------------------------
B2. Return a complex number from functions like (sqrt -1), where we
would otherwise have to signal an error: APPROVED.  Implementations are
free to invent real-value-only functions or a *REAL-VALUES-ONLY* switch
if they so choose.
---------------------------------------------------------------------------
B3. MULTIPLE-VALUE-SETQ must take argument pairs like SETQ does:
REJECTED.
---------------------------------------------------------------------------
B4a. Remove FLOAT-EXPONENT and FLOAT-INTEGER-EXPONENT, and return those
numbers as the second values from FLOAT-SIGNIFICAND and
FLOAT-INTEGER-SIGNIFICAND: APPROVED.

Now we need a new name for this.  The best that Moon and I have been
able to come up with is DECODE-FLONUM.  PARSE-FLONUM says the right
thing, but is very confusing.  Any other suggestions?  I will send out a
mini-ballot on this and on whether this function should return the sign
as a third value, flushing FLOAT-SIGN.

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

B4c. Require the result of FLOAT-INTEGER-SIGNIFICAND to reflect the
precision of the floating-point number: APPROVED.
---------------------------------------------------------------------------
B5. Add optional RECURSIVE-P argument to READ and friends: APPROVED.
There was some discussion of exactly what the error action should be in
recursive reads.  I'll send out a proposal on this shortly.
---------------------------------------------------------------------------
B6. Rename MERGE-PATHNAME-DEFAULTS to MERGE-PATHNAMES and eliminate the
default-type argument: APPROVED.
---------------------------------------------------------------------------
B7. Propose that we add a new slot, CONVENTION, to the pathname
structure, and an optional CONVENTION argument to the PATHNAME and
TRUENAME functions: withdrawn by the proposer (me).

After considering Moon's arguments and some comments by Hedrick and
Burke, I no longer believe this to be a good idea, at least in anything
like the form proposed.

Long-winded explanation:

First, I am willing to accept that each known host follows exactly one
file-naming convention.  (The manual needs to claify that "host" names a
file system, not a CPU.)  Given a host, the convention can easily be
found by a simple lookup in a site-specific table.  So the argument that
a convention slot in the pathname tells you how to print it, modify it,
etc., is just an efficiency hack.

Second, we must ask if there is a set of interesting cases where the
convention is known but the host is not.  One can imagine such cases --
"I don't know what CMU-WOMBAT is, but this sure looks like a unix
namestring" -- but I can't think of any real context in which such
partial information would be both available and useful.  As Moon points
out, there are not many cases in which the user would prefer to supply
the namestring convention explicitly.

Finally, there is the question of clarity.  The real reason I favored
this is that it seemed to me that the parsing of a file-name had two
distinct phases, and it would make things much clearer if we separated
them.  First, the implementation must dive in and extract a host name
from the namestring, and from that host name determine the convention.
Exactly how that host-name extraction works is implementation-dependent,
and will certainly change over time at most sites.  It is a function of
the set of conventions that an implementation is prepared to recognize.
Some might just scan for anything before a "::", while others might also
look for [foo] or see if there is something like "foo:" where "foo" is
in the table of recognized hosts.  Given the host, one can then do the
site-dependent table lookup to determine the convention in effect.
THEN one would parse the namestring using this convention argument as a
guide.  This parsing operation would be implementation-independent,
given that na implementation wants to provide for a given convention: we
would only need one unix-namestring parser, one ITS namestring parser,
etc.

So I was drawn to the separate convention machinery mostly by the
increased clarity of such an account over the current description.  What
I now realize, however, is that if we want to make this boundary between
the two phases of namestring parsing visible to the user, we have to
standardize it.  We have to provide a DETERMINE-CONVENTION function for
namestrings and specify all of the things that it might or must return.
We have to do this in such a way that we do not rule out extensions
which would make use of a hierarchical organization of conventions or of
partially-sepecified or ambiguous conventions.  To do this in a standard
way is a task that we could not possibly complete in time for the
current manual, and it may not be a good idea in any event.  Most
namestring parsers will have this two-layered structure, but the
potential variability of the interface between those layers is so great
that we probably want to let that be an issue between each
implementation and itself, at least for now.

So, unless there are objections, I propose that we forget about the
proposed convention argument to PATHNAME and TRUENAME, and that the
CONVENTION argument to PARSE-NAMESTRING should be specified to take a
known host-name: if this is supplied, the parsing will conform to the
conventions of that host.  I think that gives us a sufficient escape
hatch for odd cases.