[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(declare (type fixnum ---)) considered etc.
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
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
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
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:
(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
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).