Re: Array 'downto' [Was: Implementing an elegant range type]

[Robert A Duff <bobduff@world.std.com>]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes:

> I intend (eventually ;-) to provide a representation attribute for this
> purpose, for array objects and types, in my compiler.
> 
> For any array object or type A, if
> 
>    A(n)'Reverse_Element_Order
> 
> of type Standard.Boolean, is False, the elements of the nth dimension of A
> will be placed in memory with the element corresponding to the lowest index
> value in the lowest memory address. If it is True, the elements will be
> placed with the element corresponding to the highest index value in the
> lowest memory address. The default will be False. The subscript can be
> omitted for the first dimension.

I've toyed with that idea myself, but I'm not sure what use it is in
practise.

> Additionally, for any multidimensional array object or type A,
> 
>    pragma Convention(Fortran,A);
> 
> will cause the representation to be leftmost dimension varying fastest. All
> other conventions will cause the representation to be rightmost dimension
> varying fastest.

For types, that's what the RM already says, and I think many compilers
implement it.  But it seems problematic for objects.  At least, you
would have to have various restrictions.  For example, if the array is a
by-reference type, you can't be representing different objects
differently, because you might pass them as parameters.  For a type that
allowed by-copy parameter passing, you could do a massive conversion on
parameter passing, I suppose.

> Other implementors should feel free to copy these ideas if they fancy. It
> should be understood that for certain environments (e.g. a virtual machine),
> they will be unimplementable.

I don't understand why.  I can see cases where they are unimplementable,
but I don't see what it has to do with the environment.

> I am toying with the idea of a pragma Split_Array, which, when applied to an
> array object or type, causes the array to be placed in memory as a set of
> arrays (called 'columns'), one for each indivisible subcomponent of the
> array's component type. If this causes columns to have a convenient width
> (e.g. a byte or word), it could make some accesses to the array much faster
> (at the expense of making some other accesses more complicated and slower).
> Split_Array would be a kindred pragma to Pack (but they would not be
> mutually exclusive, as one may wish to pack the columns).

I've pondered the same idea myself.  Basically, you are laying things
out "inside out" -- that is, you're turning (eg) an array of records
into a record of arrays.  It sounds awfully hard to get this right, in
general, and you will need certain restrictions.  Consider passing a
component of the array-of-records as a parameter -- you need to gin up a
record, but you can only do that if by-copy is allowed.  (Or if you're
willing to implement by-ref in an extraordinarily complicated and
inefficient manner.)

In the end, I decided this kind of thing isn't worth the trouble.
Let the programmer declare a record-of-arrays, if that's more
efficient.  And if that's ugly, hide the ugliness in a package body.

- Bob