Scheme vs. CommonLisp vs. the World

[Henry G. Baker]

> I couldn't disagree more strongly.  IMHO Bignums is one of the top 10
> reasons why Lisp is a superior language.  It is all too easy to see
> integers overflow 32 bits, and wreak havoc.  I'm not against the concept of
> having a "core" Lisp, but I think it would be a big mistake to leave out
> bignum support.
> 
> Christopher (Chris) J. Vogt
> mailto:vogt@novia.net
> Omaha, NE
> http://www.novia.net/~vogt/

Sorry, we're running into a definition-of-terms problem.  I think
that bignums are outstanding, and that they should be available to
nearly every portion of the system.  I just don't think that they
should be part of the 'kernel' which has to be reprogrammed in order
to port the system.  By providing the 'hooks' to allow bignums to be
programming _in_ Lisp, this reduces the size of this kernel.  For
many, many reasons, portability and compiler size being only two of
the most obvious, it is important to minimize the size of this kernel.

So, bignums _are_ in the language; they just aren't part of the most
basic bootstrapping kernel.

One could even have (at least two) different implementations of
bignums: one which utilized cons lists of immediate fixnums, and one
which utilized single-dimensioned arrays of immediate fixnums.  And by
the way, both implementations need to have the ability to produce
immutable result objects.

I have written a number of bignum implementations in several different
languages.  Unless you are looking for the absolute highest speed,
this is _not_ a lot of code.  Furthermore, the ability to write bignum
code _in_ Lisp will finally satisfy the crypto/RSA people, for whom
the performance of the standard bignum package will probably not be
acceptable.

-- 
Henry Baker
www/ftp directory URL:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html