> * Space/performance tradeoff - I'd like to see what this is > before making decisions. I'm interested in both large Squeak > systems on high-end desktop machines AND tiny Squeak systems > running in my wristwatch or shirt pocket. It might well be > that the space hit is not that large and that fast > LargeInteger support on a tiny machine might be very useful, > especially if the machine lacks good floating-point support.

Implemented as a Plugin, the tradeoff becomes optional for each user.  You get to have the best in both worlds with the same image.  (The primitive runs just as fast, except perhaps for the first call in each session, when the system opens the DLL or shared library).
 > * Simple implementations: I'd much prefer a very > high-performance implementation. I don't want to take a huge > hit when an integer exceeds 30 bits. IE, if it's going to be > done it would be good if the final version was extremely fast.

The existing model is particularly simple, so any implementation, even if it followed the present approach, will be much, much faster.

> * Optimizing special cases:  There are lots of applications > where one only needs 32 or 64 bits. (See below). These cases > probably should be special.

I agree.  In particular, I imagine that the vast majority of bignums are created in fairly simple smallint overflow scenarios (for example, copying elements to and from a variableWordSubclass representing values larger than a SmallInteger).  I note with sadness, at times, the contortions found in some image code designed solely to avoid overflow when adding or shifting SmallIntegers.  It would be nice if there was an intermediate object somewhere between multiple precision and SmallInteger arithmetic that would not have a substantial cost as compared to the largeInteger work.  Perhaps by using the floating-point mantissa trick for IntermediateInteger values.

> * Other users of integers: For example, the random number > generator in Squeak uses floating-point to get around the 30 > bit small integer limit. Virtually all well-tested generators > are for 32 bit integers and it is a very major bit of work to > create a 30 bit generator. Dan and I found a major > performance improvement using floating-point numbers as > 'integers' when generating random numbers. If large integers > handled 32-bit integers well, then the algorithm could be > switched back, especially on small machines where > floating-point support is poor or missing.