[e-lang] Defensive consistency and integer overflow

[Mark Miller]

On 9/23/07, David Hopwood <david.hopwood at industrial-designers.co.uk> wrote:
> In general, it would be much nicer to be working in a language with
> arbitrary-precision integers

Java and Joe-E have arbitrary precision integers. Unfortunately, Joe-E
programmers tend to avoid them due to their costs, both notational and
runtime. The notational costs could be fixed. At this point, the
incremental bloat added to the Java language would, sadly, be a drop
in the bucket.

Unfortunately, the runtime costs may not be fixable without an
incompatible change in semantics.  BigIntegers in Java and the JVM are
selfish: they have creation-based EQ identity. If this were relaxed, a
variable of static type BigInteger could use the kind of tagged
pointer representations that Lisps and Smalltalks use to fit small
BigIntegers into these variables.

Javascript is differently broken. All Javascript numbers are IEEE
double precision floating point numbers. Regarding accident, I would
argue that this is much less broken than the wrapping "integers" of C
and Java. However, regarding malice, it's not clear that it's any
better.

The irony is that defensive consistency doesn't need arbitrary
precision integers. It would have been adequate for fixed precision
integers to either throw an exception or became a NaN when exceeding
its precision limit. Today, all instruction sets make available an
overflow bit on integer ALU operations. AFAIK, all languages with
fixed precision "integer" arithmetic ignore this bit and make it
inaccessible.

What's the integer situation on C#/.NET?

-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM