DISCUSSION:

More about portability of extended arithmetic:
 -- It would be highly desirable to be able to express that only a small part
    of a program depends on extended arithmetic.  If this precise information
    exists, then the problem-causing code can usually be changed to not use
    extended arithmetic or to use some adequate non-primitive extended
    arithmetic implementation.  The most natural way to express properties of
    code so that it can be recognized by the compiler is to use the language
    semantics, in this case the class system.

More about efficient integer implementation:
    In the absence of any assertion from the programmer that non-extended
    arithmetic is intended, there is no straightforward way to generate
    efficient code for integer operations.  The best simple code generation
    strategy for arithmetic is to translate "x + y" to something like:
        if (instance?(x, <small-integer>) & instance?(y, <small-integer>))
            let (res, overflow) = small-add(x, y)
                if (overflow)
		    small-add-overflow(x, y)
		else
		    res
		end;
	else
            big-add(x, y);
        end;

    In common case where all the arguments and results are small, the speed
    penalty of this implementation is at least 3 additional compare-and-branch
    operations.  This will make arithmetic at least 4x slower; in practice a
    branch is always somewhat more expensive than an arithmetic operation, and
    compare-and-branch often requires an additional compare instruction.  So in
    many implementations, a straightforward implementation of addition will be
    more like 10 times slower than the obvious single-instruction
    implementation.

    The overall speed effect on a program will depend on how much integer
    arithmetic is done -- a program that only spends 10% of its time doing
    integer arithmetic will only be slowed down by a factor of 2.  Note however
    that programs written to use the <vector> class will use integer arithmetic
    extensively, and <vector> is documented as being efficient.

    There are numerous ways that a more sophisticated compiler could generate
    better code, but:
        From a user's perspective:
           Enabling these optimizations to take place requires use of a coding
           style designed around the abilities of the compiler's sophisticated
           optimization algorithms.  Rules for an efficient coding style are
           likely to be full of exceptions and to be somewhat
           implementation-dependent.  Users would prefer a simple, portable way
           to express their intent.

        From an implementor's perspective:
           Most of these optimizations are not simple, and are specific to
           integer operations (they don't improve the performance of any other
           language constructs.)