[M3devel] INTEGER

[Mika Nystrom]

"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?

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);

(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).  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