[e-lang] Defensive consistency and integer overflow

[Mark Miller]

On 9/23/07, David Wagner <daw at cs.berkeley.edu> wrote:
> Mark Miller writes:
> >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.
>
> Yup.
>
> What did you have in mind for fixing the notational costs?
>
> I can think of a solution based on transforming the Java/Joe-E source
> code (though that seems potentially a bit unwieldy in practice for various
> boring reasons) but I'm curious what you had in mind.

For example, given:

    BigInteger a;
    BigInteger b;

then

    a + b

would expand to

    a.add(b)

Is this what you had in mind? Is it unwieldy for any reason, boring or
otherwise?


> >What's the integer situation on C#/.NET?
>
> C# has a "checked" keyword that seems like just what you'd want:
> if arithmetic inside a "checked" block overflows, an exception is
> thrown.
>
> http://msdn2.microsoft.com/en-us/library/74b4xzyw(VS.71).aspx
> http://www.codeproject.com/csharp/overflow_checking.asp

Yes, Eric Northup just posted on this as well.

And C#/.NET also has another big advantage for supporting a Joe-E-like
effort: the lack of type erasure, i.e., the availability of
parameterized type info at runtime. When coding Horton in
Joe-E/Waterken, I was repeatedly surprised at the awful consequences
of type erasure. Funny, but when I first read about type erasure, it
seemed like it would be a nice pleasant compromise.

Does mono have checked arithmetic and non-erased type parameters?
Should a Joe-E-like object-capability taming of mono be called
"Irony"?

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

    Cheers,
    --MarkM