Multiple-value-revenge of the Ballot

[Guy.Steele@CMU-CS-A]

B1.  I favor eliminating the data type (COMPLEX type1 type2), and replacing
it by the type (COMPLEX type).  This simplifies the type systems, and removes
an annoying glitch in the abbreviation mechanism, as Moon pointed out.

It does strike me as a bit strange, however, that we would provide the
specialized types (COMPLEX RATIONAL), (COMPLEX SHORT-FLOAT),
(COMPLEX SINGLE-FLOAT), (COMPLEX DOUBLE-FLOAT), and (COMPLEX LONG-FLOAT),
but not provide (COMPLEX T) [or at least (COMPLEX (AND NUMBER (NOT COMPLEX))) ].

I guess I could go either way on this one.  If (COMPLEX T) is not supported,
then certainly the rules of floating-point contagion should apply.

B2. (sqrt -1) and friends.  YES.

B3. multiple-value-setq takes multiple pairs.  NO.

B4a.  Double values from xxx-significand.  Mildly opposed.  We voted on
this before, as I recall.

B4b.  float-digits and float-precision.  Fine by me.  They aren't needed
for printing, especially if B4c is approved.  However, their existence makes
B4c easier to explain.

B4c.  Restriction on FLOAT-INTEGER-SIGNIFICAND.  YES.  I wanted to impose
a limitation like this, but didn't figure out the correct formulation.

B5.  Recursive-p in READ and friends.  YES.

B6.  merge-pathnames.  YES.

B7.  file name convention argument.  Mild YES.
--Guy