Issue: REAL-NUMBER-TYPE (version 2)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

Would your concerns be addressed if CL adopted REAL with the provision
that RATIONAL and FLOAT might not be an exhaustive partition of real?
In that way, an IRRATIONAL type (and/or perhaps others) could be added
by implementations wanting to.

Your remarks about the possibility of an irrational amount to a 
strengthening of the need for REAL, since it points up the fact that
anyone now using the indicated OR type is setting themselves up to be
confused by other number types which come along (either in future CL's
or in some particular present-day CL sub-dialect) which actually might
be perfectly ok for their application. If they could say REAL, they
could permit these unexpected types in a natural way.

The practical impact on CL programmers would be that they were advised
to do:
 (TYPECASE number
   (REAL
     (ETYPECASE number
       (FLOAT ...)
       (RATIONAL ...)))
   ...)
rather than:
 (TYPECASE number
   (REAL
     (TYPECASE number
       (FLOAT ...)
       (OTHERWISE ;presumably RATIONAL
	 ...)))
   ...)

By the way, I'm surprised by your reaction partly because there are already
other things in CL (most notably a definition of COMPLEX such that RATIONAL
is not a subtype, and such that the real and imaginary parts must be of the
same machine representation) which are not true to mathematics already. 
Given this, I'm surprised you even care whether the rest of the type system
corresponds. I would assume that any serious mathematics would want to be 
reconstructed atop CL rather than rely on its native partitionings, which 
already seem off base, as (for example) Macsyma has done. 

It seems clear to me that CL is not going to provide true representations
of mathematics. The real question is, should CL be permitted to provide
approximate representations? I think the answer is yes. I keep coming back 
to the following analogy in my mind: CL's type system is to a mathematical
type system as floats are to reals in math ... some may legitimately say
the two have nothing to do with each other, yet you can still get useful
work done even with the crude approximations. 

Indeed, the more you let the approximation -be- an approximation, the
more work you're likely to get done. I think programmers don't mind making
exceptions for things Lisp might really do, but I also think the more you
force the programmer into thinking about abstract concepts which in fact 
do not exist in any implementation, the more the programmer can feel
you're just wasting his time and the less likely he's going to be to use
this language the next time. If CL really -had- irrationals, we would modify
the definitions of things to suit irrationals. But if CL is not going to
have irrationals, there's a fine line between the extensibility issues
you raise and the practical day-to-day overhead of a programmer who may
wonder if by the time it comes to extend the language he won't be programming
in some other language anyway...

So I guess I'm willing to see a compromise, stating that RATIONAL and FLOAT
are not an exhaustive partition of REAL, but I'm observing that that 
compromise is not without cost. 

Beyond that, the issue is simple: programmers want a word to use. REAL is
the word which is used by other languages. We can avoid REAL if there is a
strong reason to do so, but we should then have some other word. 

Your critical suggestions are interesting and somewhat helpful, but if you
now make a constructive suggestion -- ``how should we proceed?'' -- it 
might be more helpful. My reading is that people are not yet so wedded to
this proposal that they wouldn't be willing to change if someone made a
reasonable, concrete, alternative proposal. What we most lack is time.