Re: issue BOGUS-FIXNUMS (initial draft)

[sandra%cdr@cs.utah.edu (Sandra J Loosemore)]

Well, I thought this issue would generate some flamage....  But before this
gets any farther, let me make one thing clear:  This proposal *is* *not*
(read my lips!  IS NOT!) an attempt to do away with either efficient "fixnum"
arithmetic or arbitrary precision arithmetic!  It is merely an attempt to
get rid of some unfortunate and nonportable terminology from the language
standard.


> Date: Mon, 11 Jul 88 17:16 EDT
> From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
> 
> This proposal might go over better if we replaced the feature with
> another, more portable, feature addressing a similar need. eg,
> 
>  SMALL-INTEGER could be defined as some range of integers which we
>  think most implementations can support efficiently (but with the
>  understanding that the important thing is to support it correctly
>  rather than efficiently). For example, maybe SMALL-INTEGER could
>  be defined as (INTEGER -2â??30 (2â??30)). [The specific bounds is open
>  to discussion, of course, I'm just proposing ``something like this''.]

Users can already define such a type (or types) on their own.  This technique
is used quite extensively in CLX, where there are about a dozen types
defined like:

    (deftype int8 () '(signed-byte 8))
    (deftype card16 () '(unsigned-byte 16))
    (deftype array-index () `(integer 0 ,array-dimension-limit))

Unlike "fixnum", these type specifiers have uniform semantics across all
implementations.  One would hope that in those implementations where they
are subtypes of "fixnum", the compiler would be smart enough to recognize
them as such.

(As an aside, there is a precedent for doing this in other languages
as well.  Many Pascal compilers, for example, only have one size of
integer that is allocated if you just say "integer".  But, if you
define a subrange type like 0..255 instead, they'll only allocate an
8-bit byte for it.)


> From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
> Date: Mon, 11 Jul 88 21:32:31 bst
> 
> Even though fixnums may
> differ from implementation to implementation, I want a standard
> way to use them when they exist rather than allow implementations
> to diverge (so that some call them fixnums, others something else,
> and so on).

Having a standard name is of little use unless it is tied to some
standard semantics.  The problem is that there is no guarantee what
you get when you say "fixnum".  There is currently no absolute
prohibition against defining the range of fixnums to be something like
100,000 to 100,010.  If you want "small integer", then by all means
define your own small integer type using DEFTYPE.  That way you're
guaranteed to have it mean exactly the same thing in all
implementations. 

> I do not accept the argument that it doesn't matter because everyone who
> provides fixnums can still provide them.  If they're not in the standard,
> users cannot in fact rely on them being provided in a standard way.
> Indeed, if we decide to allow only standard symbols in the LISP package,
> users would have to type LUCID:FIXNUM, EXCL:FIXNUM, etc. rather than just
> FIXNUM as they can now.

Why not just import the appropriate symbol into the package you're using
once, and be done with it?


> Date: Tue, 12 Jul 88 10:33:24 BST
> From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
> 
> This looks like a giant step backwards.  Some of us are interested in
> writing efficient code.  Even if some machines only have one
> representation I find it hard to believe that there are not a subset
> which are more efficient.  Are you seriously suggesting that LISP
> should counternance numbers not being arbitary precision?

Once again, I AM NOT PROPOSING TO GET RID OF ARBITRARY PRECISION
ARITHMETIC.  If your implementation supports a range of small integers
that are more efficient than larger integers, there is already a portable
way to declare them as such.  

To draw an analogy, small bignums are likely to be considerably faster and
more efficient than large bignums.  Should we assign a special name to
bignums with less than N "bigits" simply because they're faster than bignums
that are larger than that?  How useful would having such a special name be
when both N and the size of the "bigit" vary from implementation to
implementation? 

> Anyway KCL has fixnum, bignum and short fixnum.

It appears I was misinformed on this point -- I was under the impression
that KCL boxed all integers and simply preallocated a range of small
integers.

-Sandra
-------