[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%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
- Date: Mon, 18 Jul 88 16:52:03 BST
- Cc: jpff <@NSS.Cs.Ucl.AC.UK:email@example.com>
> Date: Tue, 12 Jul 88 09:08:25 MDT
> From: sandra <(Sandra J Loosemore)firstname.lastname@example.org>
What I want to establish is:  Fixnums are about as useful as, say,
int or long in C (or if not can be made so rather than be eliminated),
In KCL, fixnums can actually be compiled as ints.  It's nice to have
a standard name for efficient integers, and a standard name has to be in
the standard.  Explicit subranges are not necessarily efficient and
are often less convenient to use.
Moreover, GZ has provided some examples from Macsyma that show that
fixnums can be used with a considerable degree of portability even as
In short, the argument for eliminating fixnums seems to be based on an
overemphasis on one aspect of portability rather than a consideration
of what programmers actually do and want.
> > 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.
Well, then perhaps int and long in C are of "little use". They are
not guaranteed to be the same size everywhere.
Note too that your argument is for reforming fixnums, not for
eliminating them, and I am not arguing against reform.
> 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.
You may want it to mean "exactly the same thing" (meaning exactly the
same size); that is not what I am asking for.
Besides I don't want a small integer, I want an efficient one. A
subrange is not guaranteed to be efficient, and so does not replace
> > 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.
Note that your response about packages below does not answer this.
> > 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?
This is still not providing fixnums in a standard way. I still have
to add some conditional code for each implementation.
> > Date: Tue, 12 Jul 88 10:33:24 BST
> > From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
> 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.
The range gets ported, but the efficiency may not. Fixnums work
adequately over a wide range of implementations without requiring
implementation-specific customization of my types. I am even willing to
have some programs not work in implementations that have a sufficiently
losing notion of fixnums, just as I am willing to do this in other
> 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?
That we do not want a name for every class of more efficient number
does not show we do not want a name for any such class.
Moreover, compilers can (or at least do) get more in the way of
optimization from fixnums than they would from "small bignums".
> 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
It does "box" all integers (though fixnum declarations may avoid this in
compiled code). But the representation of fixnums is simpler than
that for bignums. It is very much like Franz in this respect.