Var is dead! Long Live CheckedPtrVar and IntegerVar!

[Mark S. Miller <vlad!mark>]

Date: Wed, 15 Aug 90 13:29:27 PDT
   From: xanadu!michael (Michael McClary)

   ...

   I had thought they were going to do something like that eventually (switching
   to bignum behavior by mashing the vtable pointer), but markm's message gave
   me the impression that this option had just been closed off.

No.  I'm curious about what in my message gave you that impression.
Having fixed-precision IntegerVars is a temporary hack until we
integrate in Wjr's bignum stuff.  The intention (as I understand it)
is that we have the following portable/machine-transmittable integral
types in X++:

Int1		2's complement -128 to 127, 8 bits
UInt1		unsigned 0 to 255, 8 bits
Int4		2's complement, 32 bits
UInt4		unsigned, 32 bits
IntegerVar	2's complement, almost infinite precision

Where "almost infinite" means limited by address space and memory
only.  In the interests of segmented architectures, we may be
interested in saying that they aren't bigger that 2^(8*32K) in
magnitude.  I haven't really thought about specifying an upper bound.
I suppose we should at least specify a lower bound on the value the
upper bound may have.

   How can they do bignum stuff if they're not Heapers, and don't have a vtable
   pointer?  (I suppose they could HOLD a heaper, and contain a switch...)

See Wjr's implementation.  They contain a switch and (depending on the
switch) either an internal fixed precision number or a pointer at heap
allocated memory (but not a Heaper).  For architectures that allow
efficient tag checking we could even have a lisp-like implementation
that doesn't take more room for the switch.

The reason we aren't using Wjr's package yet is simply the old pre-
crutch problem with destructors in temporaries.  Now that we have
crutch, we should try again.

In any case, all this is orthogonal (as far as I can tell) from making
them their own non-polymorphic root class.