[M3devel] INTEGER

[Mika Nystrom]

"Rodney M. Bates" writes:
>
>
>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.

Yes, of course, that is why they didn't do it.  I'm not sure it's
even particularly difficult.

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

Right, and I think it's enough.  What we care about here is that we can't
return the variable-sized array nor assign it to anything.  I think
it falls out rather naturally.  E.g., to take an already fairly nasty
example:

PROCEDURE F() : ARRAY [0..1] OF T =
  VAR x : NEW(ARRAY OF T, 2);
  BEGIN
    RETURN x 
  END F;

here there is an implicit type check on return.  This is probably
already implemented by the compiler as:

PROCEDURE F(VAR retval : ARRAY [0..1] OF T) =
  VAR x : NEW(ARRAY OF T, 2);
  BEGIN
    retval := x; (* implicit shape check *)
    RETURN
  END F;

Another fairly nasty example:

PROCEDURE G(x : ARRAY OF T) = ...

VAR x : NEW(ARRAY OF T, 2);
BEGIN G(x) END

This is no different from writing

VAR x : ARRAY [0..1] OF T;
BEGIN G(x) END

and I don't see how introducing the variable size makes it really
any more difficult.  If the compiler writer doesn't know how to do
it in one particular case he can also just punt the problem to heap
allocation.

Maybe there is something I'm missing but it has always bugged me
that most of the time I have to heap-allocate array temporaries.

   Mika