[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: Sandra J Loosemore <sandra%cdr@cs.utah.edu>*Subject*: Issue BOGUS-FIXNUMS (Version 2)*From*: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>*Date*: Sun, 31 Jul 88 16:39 EDT*Cc*: cl-cleanup@SAIL.STANFORD.EDU*In-reply-to*: <8807281900.AA05586@cdr.utah.edu>

I approve of BOGUS-FIXNUMS:TIGHTEN-DEFINITION for the most part, but I have a few comments and doubts to offer. (3) Remove BIGNUM from the table of standard type specifier symbols on page 43 of CLtL. I don't approve or disapprove of this part; I'm of two minds about it. It may be an unnecessary incompatible change. If anyone opposes it, I will go along with them. (4) State that the constants MOST-POSITIVE-FIXNUM and MOST-NEGATIVE-FIXNUM are allowed to have a value of NIL to indicate that the implementation does not have a particular FIXNUM representation distinct from other integers. I don't think that allowing these constants to be NIL enhances portability. That means a lot of "gratuitous" checking for NIL would be required. I think a better idea is to require that these constants always have integer values, and that if an implementation really cannot identify any efficient range of integers, it should set these constants to arbitrary values consistent with the requirement that (SIGNED-BYTE 16) is a subtype of FIXNUM. Think about a program that would use these constants to parameterize an algorithm, as in the example taken from Macsyma that does modular arithmetic using the largest prime modulus that fits in a FIXNUM. What does such a program gain by allowing NIL here? In fact I would think that an implementation with only one representation for integers could define integers represented in a single bignum-digit to be its fixnums; those are more efficient than larger integers, just not by as large a factor as in some other implementations. (5) Introduce a new constant, MAX-INTEGER-LENGTH. This is the maximum number of bits appearing in any integer; therefore, it is an upper bound on the INTEGER-LENGTH function. The value can be NIL if there are no limits short of memory availability. Again I don't think allowing this constant to be NIL makes sense. You surely aren't saying that if this constant is non-NIL, the implementation guarantees that there is enough memory to create at least one integer of the specified length, let alone as many integers of that length as the program might need. Thus memory availability is always a limitation, and implementations that truly have no representation limit on the number of bits in an integer should set this constant to a value that is guaranteed to be higher than the memory limit. Possibly what I just said is an argument that this constant should not exist, because there is no correct way to use it. It tells a portable program nothing about what it can or cannot do. Or possibly it's an argument that under your definition, any implementation with a non-NIL MAX-INTEGER-LENGTH would be in violation of the bottom of CLtL page 13, which says there is no limit on the magnitude of an integer other than storage. By that reasoning the Symbolics 3600 would be in violation, since its address space exceeds its bignum representation limit. However, the bignum representation limit is large enough that numbers of that size become impracticably slow [see, memory isn't the limit either, the real limit can be asymptotic speed of arithmetic algorithms] and I doubt that Symbolics would care to change their bignum representation to allow larger bignums which no one could actually use. Introducing a new constant to describe the maximum size of integers makes it possible to describe an implementation's exact limitations on the range of integers it supports. This constant would also be useful for the description of subset implementations. It's true that it's useful to describe these aspects of an implementation. I'm not sure that that justifies putting the description into the Common Lisp language, rather than English. On the whole, I weakly oppose part 5. Rationale: Many programmers already use FIXNUM to mean "small integer"; this proposal makes this usage portable, and allows programmers to use the FIXNUM type specifier in a way similar to how the "int" type is used in C. I.e. as an unending source of bugs and portability problems. :-( Maybe I'm just down on C today.

**References**:**Issue BOGUS-FIXNUMS (Version 2)***From:*sandra%cdr@cs.utah.edu (Sandra J Loosemore)

- Prev by Date:
**bignums** - Next by Date:
**ISSUE: VARIABLE-LIST-ASYMMETRY (Version 1)** - Previous by thread:
**Re: Issue BOGUS-FIXNUMS (Version 2)** - Next by thread:
**MULTIPLE-VALUE-SETQ and SYMBOL-MACROLET interaction** - Index(es):