[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue BOGUS-FIXNUMS (initial draft)
- To: firstname.lastname@example.org, sandra <@cs.utah.edu:sandra@cdr>
- Subject: Re: issue BOGUS-FIXNUMS (initial draft)
- From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
- Date: Mon, 11 Jul 88 21:32:31 bst
> Date: Mon, 11 Jul 88 11:28:42 MDT
> From: sandra <(Sandra J Loosemore)email@example.com>
Do I understand this? You are proposing to eliminate fixnums from
I would certainly oppose such a change. 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).
> Since CLtL does not guarantee anything about the range of fixnums
> (saying only that they will *typically* be between -2**n and 2**n - 1,
> for n not less than 15), any user program that uses FIXNUM or BIGNUM
> declarations is already nonportable.
This depends on what you count as portable. There may be no gain
in efficiency, but the program will still work if care is taken
to check the range and in many cases even if not. Moreover, I
can know that this kind of thing is called "fixnum" and not
> Current Practice:
> KCL has only a single representation for integers,
It has two -- or three: see Franz below.
> Franz Lisp [has] three different integer representations.
You might say Franz has three, but small fixnums have the same format
as larger ones; the difference is that they live in a known part of
memory and new ones are never allocated. If you count this as three,
KCL also has three.
> Cost to users:
> Slight, at least in portable code. If implementors continue to
> support the FIXNUM and BIGNUM type specifiers, existing (nonportable)
> user code that relies on them would continue to work in those
I think it is a mistake to think that "nonportable" code does not count.
It is useful to have a standard way to do something even if it does not
work everywhere, and the optimizations for fixnums are important enough
that most implementations provide some.
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.
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Daltonfirstname.lastname@example.org
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton