Comments and poll on () [long message]

[Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>]

Summary (new items called E and F are defined in `Detail' section below):

 I strongly prefer: D, F.

 I strongly oppose: A, B, C, E.

 Rationale:
  I strongly oppose A, B, and C because I do not think that it is acceptable to
  have "may be" involved in this definition.  Note that C seems especially idiotic
  since it introduces an incompatible change and yet even having paid this price
  still does not go to enough work to make sure that all implementations agree.
 
  In fact, I could live with E because it is at least well-defined, but it
  seems to defeat the purpose of separating #F and (). If the only purpose 
  of doing this was just a stepping stone to position D, then I'd rather 
  just get to D all in one shot.

Detail:

    Date: Mon, 19 Feb 90 16:38:25 -0500
    From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>

    There are (at least) four possible positions in the area of consideration:

    A. #F and () may be identical, and () may be false;

    B. #F and () may be identical, but () is true if they are distinct;
						  ^
Just to clarify, pragmatics dictates that "iff" is implied here.

    C. #F and () are distinct, and () may be false;

    D. #F and () are distinct, and () is true;

I would add:

    E. #F and () are distinct, and () must be false;

    F. #F and () must be identical (and must be false);

There are some pragmatically nonsensical ones which I've omitted.
The following table captures the above:

	identical?	() false?

     A.    maybe	   maybe
     B.    maybe           iff not identical
     C.    no		   maybe
     D.    no		   no
     E.    no              yes
     F.    yes		   yes

Since I've got you on the line, let me make one more appeal to
portability issues:

I converted Macsyma (a 100,000 line piece of code) from Maclisp/Zetalisp
to Common Lisp.  Probably -the- hardest thing to convert was QUOTIENT.
The reason was that (QUOTIENT 3 4) had a straightforward rewrite and
(QUOTIENT 3.0 4.0) had a straightforward rewrite, but mathematically the
two operators were not related.  The problem is that (QUOTIENT X Y) has
no efficient rewrite because you may not know the types of X and Y and
cannot efficiently select a rewrite.  This means that compatibility code
ran yuckily because the translation had to do something to the effect of:
 (IF (OR (TYPEP X 'FLOAT) (TYPEP Y 'FLOAT)) (/ X Y) (TRUNCATE X Y))
That is, the definition of QUOTIENT was not usefully well-defined.  It only
-looked- well-defined because it was not ambiguous.

In psychology class, we studied something called "natural concept".  The
claim went something like that a `natural concept' is a categorization
that can be defined without the use of "or".  That is, if you defined
that a `bleen' was something that was `blue up until tuesday or that was
green afterward.'  Another example was that something was `smig' if it
was `big and blue or small and green.'  The professor used to make the
observation that this was a kind of categorization that people do not
normally do.  But I never saw the relevance.  So what?  So they don't do
it.  What good is that to me.  Well, the good seems to me to be here and
now.  So that I can recognize that what you are doing is provably not
going to map onto the natural conceptual structure of normal people. 

There is only one category of people I can think of who regularly employ
these so-called `unnatural concepts': politicians.  That's because they
don't ever really decide things.  They just make `plausible looking'
statements that superficially appear to bring people together when
really they have only papered over deep-rooted discontent with wording
that gives the momentary illusion of progress.  So what I see right now
is a big red flag of an organization that is growing up to be just as
uglily political as the `commoners' it seeks to be unlike.

I am convinced that there is no universal right to be had here--so I
don't think the details of which road you take is going to matter.  They
all lead different places but each of the places is respectable and
people will get work done.  But driving in your stake at a fork in the
road and refusing to go further will clearly cost people real amounts of
time and effort--day in and day out, people will pay for every
individual's unwillingness to compromise and produce a clear answer to
this problem.  The solution to the porting problem I described for
QUOTIENT will be the kind of thing that will haunt programs for years to
come.

And one last parting point: 5 years is a long time.  Even if you don't
think that things are "cast in concrete" by this standard because it
must be reviewed every five years, consider that five years may be
longer than the funding cycle of many projects that have to work in
whatever standard is produced.  Perhaps worse, 5 years may be time
enough to evolve still more code so that the decision to change things
is even more costly at that point--and -then- wait until you see the
politics that come when you try to change it.  If you think something is
a problem now, then now is the time to fix it.