[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Any vagueness on max size of bignums is no more acceptable
than it is for arrays or fixnums or floats, all of which have plenty of
constants defining *their* limits!
I think we should introduce an INTEGER-LENGTH-LIMIT constant which would be
the largest value that INTEGER-LENGTH could return.
Presumably, then we also need a constant called CONS-LIMIT, which is the
maximum allowable length of any list. After all, someone might want to
use a list of T's and NIL's instead of a bit vector, and it weakens the
standard if we don't tell him exactly how long this list can be.
That's part of my thesis work, so I won't insist on it being in the standard
right now! A CONS-LIMIT of some sort would be necessary in a Lisp system
that produces programs for embedded systems, however, so it's not as
ridiculous as it appears to be...
Maybe the scope of the smiley face at the end of your message was meant
to be the whole message?
Sorry, I was quite serious. If bignum size limits are silly, then why are
array size limits not silly? Seems inconsistent.
Here's a (serious) meta-proposal: every type of potentially unbounded
size must have limit parameters. This would include arrays of all types,
numbers (both floats and rationals), packages, random states, compiled code,
hash tables, and structures. There wouldn't be any need for a CONS-LIMIT,
because individual conses are always the same size, and a possible LIST-LIMIT
would not be meaningful, because LIST is (OR CONS NULL).
Right now the only limits are on arrays, fixnums, and floats, so there would
be a lot of extra parameters. On the other hand, I've observed some rather
wild variation in the number of bits in a random state, which affects the
quality of random number generation. An unlucky user of packages may find
that a package is implemented with a hash table, which is implemented with
an array, which has an ARRAY-DIMENSION-LIMIT of 1024, limiting the total
number of symbols in a package to that many. I'm sure we're all familiar
with the sort of terminology that users apply to implementors when tricks
like this come to light...
Anyway, if all this is stupid, let me know and I'll shut up.