Short/extended integer proposal:

Classes:
    Add sealed classes <extended-integer> and <short-integer> as
    disjoint subclasses of <integer>.

    [Cassells suggested via mail that either <extended-integer> or
     <short-integer> might not be subclasses <integer>.  I can't think of any
     reason why they wouldn't be, so throw the question back to him.]

Interaction w/ extended integers and rationals:
    Any integer representable as a <short-integer> is also representable as an
    <extended-integer>, thus there are two semantically distinguishable
    representations for mathematically identical small integers.  "as" can be
    used to convert between the two representations:
        as(<extended-integer>, x)
        as(<short-integer>, x)

    Conversion to a <short-integer> may cause overflow, see below.
    
    "extendedness" is contagious.  If the operands to an arithmetic operation
    are a mix of <short-integer> and <extended-integer> or <ratio>, then the
    result is done using extended arithmetic, cannot overflow, and produces an
    <extended-integer> or <ratio> result.
    [Cassels questioned the need for contagion.  It is not strictly
     necessary of course, but if "1" and "length(x)" are short integers,
     then it can significantly reduce the number of explicit coercions
     needed in extended-integer expressions.  I could go for explicit
     coercions, but only if we also flush float contagion (which might be
     nice in itself, see float/rational note.)

Overflow:
    <short-integer> is closed under arithmetic and logic operations.  If the
    mathematically correct result cannot be represented as a <short-integer>,
    then the condition <short-integer-overflow> "should" be signalled.

    <short-integer-overflow> does not have any standard slots or any
    associated standard restarts.

Integer literals:
    <short-integer> is the default integer representation.  The class of
    "1" and "#x3c" is <short-integer>.  Compilation of an unqualified
    reference to an integer too large to be represented as a
    <short-integer> (e.g "17293091823098132") will cause a compile-time
    error. 

    A literal syntax is needed for extended integers so that large
    integer constants can be entered.  The extended syntax is only
    needed for large integers, because in code using extended arithmetic
    it is harmless to use short constants for small values (due to
    contagion.)

    I propose that the extended integer sytax be the normal syntax with
    a trailing "N" (for exteNded), like "17293091823098132N".  This is
    similar to the float literal syntax, but does not conflict with it
    (as E or X would.)   Note that this qualifier is also available for
    hex, octal and binary literals, e.g. "#xffffffffN".

Size:
    <short-integer> should be "close to" the native "int" size, but is likely
    to be somewhat smaller.  There is no size guarantee, but the intent is
    that it should normally be possible to use <short-integer> arithmetic for
    array and vector index calculations.

    This should be explicitly adressed; I see three possibilities:
     1] All <sequence> indices are <small-integer>s.
     2] All predefined <sequence> types have <small-integer> indices.
     3] No guarantee is made, and either small or extended integers may be
        used. 

    These two constants hold the most negative and most positive
    <short-integer> values:
        $minimum-short-integer
        $maximum-short-integer

Limited integers:
    LIMITED can be used to make subtypes of <short-integer> and
    <extended-integer> as well as <integer>.  min: or max: is specified
    for a <short-integer> limited type, the limit must be a
    <short-integer>.

    Note that:
        limited(<integer>, min: $minimum-short-integer, 
                           max: $maximum-short-integer)

    is *NOT* equivalent to <short-integer>.  This type describes any
    integer (short or extended) that falls in the range of a short
    integer.

    One can also meaningfully say: limited(<extended-integer>, min: 3, max: 5)
    This is an extended integer that is known to have a small value.

Extended/ratio semantics:
    The numerator and denominator of a <ratio> is always an <extended-integer>.
    "/" not defined on <short-integer> (except when an operand is already
    extended, as by the extended contagion rule.)

Interaction w/ floats:
    The second argument to TRUNCATE/ that TRUNCATE defaults is 1N, i.e.
    extended one, thus the first value of TRUNCATE is always an extended
    integer.  If TRUNCATE/ is called with a float and a <small-integer>,
    then the result will be a <small-integer> (or an overflow error is
    signalled.)  The same is true for FLOOR, CEILING, etc.  

    Rationale: The integer parts of many floats can't be represented as a
    <short-integer>.  We want allow extended TRUNCATE for large floats,
    but also want to able to truncate small floats w/o dragging in the
    extended/ratio library.  Small floats can be truncated by:
        truncate/(sfloat, 1)


Numeric AS proposal: 

Un-extended Dylan AS can convert:

Generalized instances of:		To these classes:
	<rational>			<single-float>
					<double-float>
					<extended-float>

Generalized instances of:		To these classes:
	<float>				<single-float>
					<double-float>
					<extended-float>

Generalized instances of:		To these classes:
	<integer>			<short-integer>
					<extended-integer>

Rationale:
    AS should not be redundant with explicit coercion functions such as
    TRUNCATE, especially where it is apt to be ambiguous, such as
    coercing ratios or floats to integers.
    
    If <float> to <rational> conversion is allowed, then RATIONALIZE should be
    eliminated.

    Coercion to <float> (as opposed to the instantiable subclasses) is
    deliberatly not specified, since the result float precision is ambiguous.


Float/rational semantics:

    What is the "mathematical value" of a float?  (as referenced in the
    definition of =.)  Probably this means the rational which the float
    precisely represents, which is dependent on the floating point
    implementation and format.  This means that "1.2 = 6/5" is false and
    "1.2 = 5033165/4194304" would be true if 1.2 is an IEEE single
    float.

    RAM: I suggest that there be no methods for comparison of mixed
    float/rational operands.  As well as simplifying the definition for normal
    floats, it eliminiates problematic comparisons with IEEE special values
    (see below.)  The main cost that I see is that casual comparisons with "0"
    or "1" wouldn't work.  ZERO?, POSITIVE? and NEGATIVE? would need to have
    distinct <RATIONAL> and <FLOAT> methods.


IEEE float issues:

== (ID?)
    == is defined as "computationally indistinguishable".  Positive and
    negative 0 are computationally distinguishable, thus "-0.0 == 0.0" is
    false.

NANs
    RAM: I strongly believe that it is a very bad idea to forbid Dylan to be
    IEEE compliant in any reasonable way (w/o using a different set of
    predicates.)   What is gained?  My guess is that the reasons were:
     1] The trichotomy rule holds in "naive arithmetic" and is thus easier to
        understand.  [But exceptions can be ignored in simple presentations.]
     2] The restrictive contract for < and = is useful in writing generic code
        that depends on ordering relationships.
     3] Basing everything on < and = makes it simpler to define new kinds of
        numbers.  (which can be had by defining <number> methods that delegate
        <=, /=, etc., to < and =.)

    What is meant by saying that "generic comparison will not be IEEE
    compliant"?  Are NaNs greater than all other floats? [which a bitwise
    comparison would give.]

    I think that what this issue really comes down to is whether comparison of
    incomparable values is allowed to return false, or is considered to be
    erroneous (should signal an error.)  Note that this issue appears with
    other IEEE exceptions, see the next item.

What exceptions is trapping enabled for by default?
    IEEE code often depends on being able to quietly overflow to infinity and
    underflow to a denormalized number or 0.  I suggest that trapping on IEEE
    exceptions should be off by default (no error signalled.)  This is the
    default in all of the IEEE C implementations I know of.

    If trapping were the default, there would be two problems:
     -- Calling non-Dylan functions would become more expensive and/or
        complicated, since non-Dylan code often depends on non-trapping
        behavior, and trapping is usually controlled by a "big switch" in the
        processor status.
     -- There would be greater need to define a standard way to control float
        trapping, since portable code would need to do this in all
        environments it runs in.  In contrast, with a non-trapping default,
        trapping could be enabled for debugging in an idiosyncratic way.

< w/ IEEE special values and rationals.
    Is "some-float-positive-infinity > any-rational" always true?
    Is "some-float-NaN = any-rational" always false?

Any code literal format for:
    +/- 0 (probably obvious)
    infinities (non-obvious but possibly useful)
    NaNs (not so useful, partly because there are many NaNs, and none of them
        are = to anything.)