The Gwydion group has thought some more about integer implementation, and we
have concluded that:

 -- we really do need a fixed integer type that gets overflow errors, and
 -- we also want to be able to use indefinite-precision extended arithmetic
    when we need it. 

Since Apple seems unwilling to go with an overflowing fixed integer model at
present, some degree of incompatibility will exist between our
implementations.  Portability problems will arise when:
 -- Code written for CMU Dylan is run on Apple (since CMU code will contain
    references to number classes or types that are meaningless and undefined
    in the Apple implementation), and
 -- If Apple does decide on some fixed integer proposal that is significantly
    or spuriously incompatible with what CMU has done, then total confusion
    will reign.


Some context:

We thought a great deal about the issue of interactions between fixed integers
and non-Dylan code.  We do agree that the usefulness of a fixed integer
"missing a few bits" is greatly reduced in an environment that is expected to
make extensive use of external code.  

Our current plan is to have a full-word <fixed-integer> which means the same
thing as C "long".  This integer will only have one representation which is in
effect "immediate".  We plan to (in general) use a two-word object reference
to allow many different types with full-word "immediate" data.  In addition to
being useful for integers and single-floats, this also allows efficient
representation of external object references (i.e. a C pointer with a Dylan
type tag.)

In our "no tag" scheme, it turns out that most typed slot can still be
allocated as a single word, so we don't expect to sacrifice much speed or
space due to having two words in general, and we expect to gain quite a bit in
predictable efficiency by never heap consing fixed integers or external object
references.

This implementation strategy does eliminate the possibility of overflow on
receiving full-word integers from external code, which we felt was the biggest
problem raised by our earlier integer proposal.

However, implementing a full-word fixed integer means there are no extra bits
that can be used for guard bits to avoid intermediate overflow in arithmetic
expressions.  Use of guard-bits was the only implementation strategy discussed
at the last partners meeting which didn't demand output type assertions on all
intermediate results.  So our desire to have a full-word fixed integer has
become another reason why it is a bad idea in our implementation to require
quiet overflow to extended arithmetic.

If Apple hasn't changed its position since our last discussion, then the best
we can do is come up with broad definition of fixed precision arithmetic that
minimizes the problems that will be encountered in porting Dylan programs
between our two systems.  We are distributing a proposal describing our view
of how to best do this.