[M3devel] INTEGER

[Rodney M. Bates]

Mika Nystrom wrote:
> "Rodney M. Bates" writes:
>> 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.
> 
> Speeeaking of stack allocation's being possible owing to LIFO lifetimes.....
> 
> The Green Book says the following:
> 
> "[Lisp, ML, Smalltalk, and CLU's] general disposition towards heap allocation
> rather than stack allocation remains"
> 
> May I draw the conclusion that exposing the difference between stack and
> heap allocation in the language is fair game for the Modula-3 definition?

I think the distinction is already exposed.  If it's created by NEW, it's
heap allocated.  If it's a declared variable by VAR, it's stack allocated.

> 
> What I'm getting at is this.  If my LONGINT proposal is workable, the
> following ought to be workable too:
> 
>   VAR a : NEW(ARRAY OF T, n);

I seem to recall an argument the original designers made to the effect
they felt declared variables of non-constant size were not worth the
complication over just heap allocating them.  I don't remember where,
or the details.  But yes, it could be made to work, I think.

> 
> (Note: no REF, also no =.)  It's an object upon which it is legal to
> perform exactly those things that are legal to do to b^, where previously
>    
>   b := NEW(REF ARRAY OF T, n)
> 
> I don't have a good name for the type of a ("evanescent array"?), but
> I think being able to do this would make it possible to write efficient
> code in ways that today only C++ (to my knowledge) allows.  I think the
> Modula-3 rules on what can (more importantly can't) be done with open
> arrays may be enough to restrict the feature so it doesn't lead to new
> complications (in the language definition---the implementation I'm not
> sure about). 

To be precise, the severe limitations on open arrays apply only to how
you can use an open array _type_.  A _variable_ (or formal, field, element
of open array, WITH-temp, etc.) of open array type can be used just
about any way one of fixed array type can be.

  The lowest levels of the implementation would use alloca
> with a fallback to heap allocation if for some reason variable-sized
> stack objects are not allowed.
> 
> LONGINT is then a rather natural specialization of the same rules.
> (Cf. ARRAY OF BITS 1 FOR BOOLEAN vs. SET OF.)
> 
>      Mika
> 
>