(declare (type fixnum ---)) considered etc.

[David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>]

    Date: Wed, 23 Jul 1986  10:39 EDT
    From: Rob MacLachlan <RAM@C.CS.CMU.EDU>


	Well, I had previously believed that the FIXNUM declaration was
    reasonable, but this was based on the erroneous belief that an array
    index must be a fixnum.  If it is fact the case that some
    implementations have small (2^16) fixnums, then this is a serious
    source of non-portability.  A possible solution would be to have an
    INDEX type which is (INTEGER 0 (ARRAY-DIMENSION-LIMIT)).

	In any case, I think there are valid arguments for retaining the
    FIXNUM declaration:
      1] Much existing code would have to be changed.  This code will probably
	 work on any implementation for some range of inputs.
In my opinion, that is one of THE poorest reasons to keep it.  Why have
any semantics at all?
      2] There is precendent for sacrificing portability to gain
	 efficiency.

    The problem with saying something like (SIGNED-BYTE 32) is that it is
    probably just as arbitrary as FIXNUM, yet is unlikely to be a good
    match for a given implementation.  In fact in this particular case,
    nearly all implementations on conventional hardware would be forced to
    consider bignums.

Back to semantics again.  How can a program that specifies it is using
fixnums possibly return the right answer reliably if the size of the
fixnum is variable by the implementation?  If a program is going to deal
with (signed-byte 12) it should say that, instead of FIXNUM.  Does the
following make anybody feel any better:
	(eval-when (compile)
	  (unless (subtypep '(signed-byte 20) 'fixnum)
	    (warn "This program is using (unsigned-byte 20), ~@
		   but these a subtype of fixnum in this ~@
		   implementation.  Efficiency will be lost!")))
Using (signed-byte 20) >>properly<< reflects the intent of the
programmer, and the above warns that they will not be efficient.

    It seems that FIXNUM is no less portable than FLOAT, since nothing is
    guaranteed about float exponent range and precision.  A Common Lisp
    program which uses floats cannot be totally portable.  One could take
    this as an argument against the currently system of float types, but
    I don't have a better solution.

Good point.  The difference with fixnums is that they are (a) exact and
(b) have overflow provision (into bignums).

    I suggest that there should be some short integer type which is
    defined to have a reasonably large magnitude (> 2^20).  This is
    analogous to the float types which have suggested minimum precisions.
    Note that CLTL currently suggest (p 14) that FIXNUM be at least
    (SIGNED-BYTE 16), so uses of FIXNUM consistent with this can be
    considered portable.

I agree with shebs: we don't need another data type.

BTW, When I say (signed-byte 32) I really mean (signed-byte 31) and when
you say (signed-byte 16) you really mean (signed-byte 15).