[M3devel] INTEGER

[Rodney M. Bates]

Oh, I get it!  You are proposing a _mixed_ approach, where the values
the programmer can designate are of fixed (though possibly nonstatic)
size (like open arrays) but the intermediate results are of unbounded
size that re-adapts to hold the actual value each time an operator is
evaluated, (like BigInteger).  And because only intermediate results
work this way, they can be stack allocated, because intermediate
results have LIFO lifetimes.

These are quite different approaches to arithmetic.  It does seem
at least a bit strange to mix them in this way.

Mika Nystrom wrote:
> Mika Nystrom writes:
> ...
>> I am not worried as you are by the range problem.  The saving grace is
>> that the language has very few arithmetic operators on integers.  
>> + - * DIV MOD.  It's not hard to do range arithmetic on these such that
>> one can easily figure out how much memory is required to hold intermediate
>> results.  If you're happy with alloca (I don't mind it), that's what
>> you do.  You have three options in so far as calculating the required
>> space:
> ...
> 
> To clarify a bit further, my proposal is that the ranges be lost in
> the evaluation.  Everything in the expression is simply of type LONGINT.
> When the final result is assigned to a variable, there is a range check
> (which can be dispensed with if the compiler can prove that there can
> be no overrun).
> 
> Isn't this how INTEGER subranges work?
> 
> a : [0..2];
> b : [0..1];
> 
> a := 4*b - 2*b

Well, not really.  INTEGER intermediate results (even when the operands
have subrange type) are computed in the fixed size INTEGER.  This could
sometimes be a lot bigger than the subranges and in some cases big enough
to hold all possible results, given small subrange operandss.  But they
are still fixed size (and maximally efficient).  The intermediate result
can still overflow in many cases.  This is quite different from a size that
always adapts to the actual value computed, every time the operator is
evaluated, and thus can never overflow.

I thought you were trying to do this in your proposal, just with bigger
sizes.

Of course, what happens when an overflow occurs is a different question.
Not very satisfactorily handled now, even for INTEGER, IMO.  But it is
not really possible in any language to handle overflows both well and
efficiently, given current hardware.  In any case, it's an orthogonal
issue to when overflows happen.

> 
>      Mika
>