Records that could be arrays

Records that could be arrays

[Justin Gombos]

I noticed this example code in 5.4.4 of the Ada Quality and Style
Guide:

  type Coordinate is
     record
        Row    : Local_Float;
        Column : Local_Float;
     end record;

  type Window is
     record
        Top_Left     : Coordinate;
        Bottom_Right : Coordinate;
     end record;

Would anyone here write something like that?

They are trying to illustrate that records should not always be flat,
which is a fine example for that purpose, but this seems to set a poor
example.  Does anyone see a reason to use a record when an array can
be used?  My version of the same structure would look more like:

  type Axis          is (Row, Column);
  type Window_Vertex is (Top_Left, Bottom_Right);

  type Coordinate is array (Axis)          of Local_Float;
  type Window     is array (Window_Vertex) of Coordinate;

I have set a rule for myself: Composite types composed solely of one
type of element should be declared as arrays rather than records.
I've never seen this rule in a coding standard.  The idea is that you
can be more expressive with an array.  Example- there are more options
when it comes to an arrays role in control structures.  Plus the
"others =>" notation is available.  Thoughts?

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: Records that could be arrays

[tmoran]

> type Coordinate is
>    record
>       Row    : Local_Float;
>       Column : Local_Float;
>    end record;
  In mathematics, one usually gives a coordinate as (x,y), while in
graphics it's often (vertical, horizontal).  Inadvertently switching
the order can be an annoying bug.  But with
   type Rows is new Local_Float;
   type Cols is new Local_Float;
the compiler's type checking can point out such errors.  In that case,
of course, you have to use a record with
        Row    : Rows;
        Column : Cols;
and cannot use an array.
  If your code might one day have to accomodate 3-D coordinates, then
        for A in Axis loop
          Sum := Sum + V(A)**2;
needs no change, while
        Sum := V.Row**2 + V.Column**2;
will need a makeover, and thus is much less desirable.

  The general point is that sometimes an array fits the problem better
and sometimes a record fits it better.  A rule that says "hey, they're all
Local_Float so it should be an array" is much too limiting.

Re: Records that could be arrays

[Wilhelm Spickermann]

Hi,

Justin Gombos wrote:

> I have set a rule for myself: Composite types composed solely
> of one type of element should be declared as arrays rather than
> records.
...
> Thoughts?

I think it depends on the meaning of "type". The three floating
point numbers in a polar coordinate system are of three
different _kinds_ and should be put into a record and not into
an array -- even if they have the same _type_.

Wilhelm

Re: Records that could be arrays

[john Doef]

Justin Gombos a écrit :

> I noticed this example code in 5.4.4 of the Ada Quality and Style
> Guide:
[...]
> can be more expressive with an array.  Example- there are more options
> when it comes to an arrays role in control structures.  Plus the
> "others =>" notation is available.  Thoughts?
"others =>" is availabe for records too.

JD.

Re: Records that could be arrays

[Jean-Pierre Rosen]

Justin Gombos a �crit :
> I have set a rule for myself: Composite types composed solely of one
> type of element should be declared as arrays rather than records.
> I've never seen this rule in a coding standard.  The idea is that you
> can be more expressive with an array.  Example- there are more options
> when it comes to an arrays role in control structures.  Plus the
> "others =>" notation is available.  Thoughts?
> 
I beg to disagree here. Arrays are for *iterative* structures, if you 
don't have a for loop over an array, it should be a record.

The fact that all components are of the same type may be an accident 
that changes during program evolution.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Records that could be arrays

[Stephen Leake]

Justin Gombos <rpbkbq.xax.gld@uluv.kbq> writes:

> I noticed this example code in 5.4.4 of the Ada Quality and Style
> Guide:
>
>   type Coordinate is
>      record
>         Row    : Local_Float;
>         Column : Local_Float;
>      end record;
>
>   type Window is
>      record
>         Top_Left     : Coordinate;
>         Bottom_Right : Coordinate;
>      end record;
>
> Would anyone here write something like that?

Yes; Windex has it. Although if I was rewriting it from scratch now,
I might use an array.

> They are trying to illustrate that records should not always be flat,
> which is a fine example for that purpose, but this seems to set a poor
> example.  Does anyone see a reason to use a record when an array can
> be used?  My version of the same structure would look more like:
>
>   type Axis          is (Row, Column);
>   type Window_Vertex is (Top_Left, Bottom_Right);
>
>   type Coordinate is array (Axis)          of Local_Float;
>   type Window     is array (Window_Vertex) of Coordinate;
>
> I have set a rule for myself: Composite types composed solely of one
> type of element should be declared as arrays rather than records.
> I've never seen this rule in a coding standard.  The idea is that you
> can be more expressive with an array.  Example- there are more options
> when it comes to an arrays role in control structures.  Plus the
> "others =>" notation is available.  Thoughts?

I usually lean towards arrays, partly for the reasons you give, partly
because I have library utilities that work much more nicely with
arrays than records; Text_IO and containers for example. I can
create a Text_IO procedure Put for an array with a simple
instantiation; for a record, I have to use auto_text_io.

But records are deeply embedded in my psyche; these types just feel
more natural as records than arrays. I guess we need to catch the kids
in high school, and teach them to use arrays instead of records.

-- 
-- Stephe

Re: Records that could be arrays

[Stephen Leake]

Wilhelm Spickermann <zulo.20.unbenutzbar@spamgourmet.com> writes:

> Hi,
>
> Justin Gombos wrote:
>
>> I have set a rule for myself: Composite types composed solely
>> of one type of element should be declared as arrays rather than
>> records.
> ...
>> Thoughts?
>
> I think it depends on the meaning of "type". The three floating
> point numbers in a polar coordinate system are of three
> different _kinds_ and should be put into a record and not into
> an array -- even if they have the same _type_.

I don't think that follows; the names indicate the kind. The names are
the same whether it's an array (the index name) or a record (the
component name).

Following Randy's suggestion, it might make sense to use different
types for the three different polar coordinates. But I would not go
that far.

-- 
-- Stephe

Re: Records that could be arrays

[Stephen Leake]

Jean-Pierre Rosen <rosen@adalog.fr> writes:

> Justin Gombos a �crit :
>> I have set a rule for myself: Composite types composed solely of one
>> type of element should be declared as arrays rather than records.
>> I've never seen this rule in a coding standard.  The idea is that you
>> can be more expressive with an array.  Example- there are more options
>> when it comes to an arrays role in control structures.  Plus the
>> "others =>" notation is available.  Thoughts?
>>
> I beg to disagree here. Arrays are for *iterative* structures, if you
> don't have a for loop over an array, it should be a record.

This is a good point. However, in my experience, I often end up using
a for loop in ancilliary places, even if there is no for loop in the
main use of the type.

For example, Text_IO Put, Get, and AUnit checks, are more easily done
with for loops.

> The fact that all components are of the same type may be an accident
> that changes during program evolution.

Yes.

-- 
-- Stephe

Re: Records that could be arrays

[Justin Gombos]

On 2006-02-23, tmoran@acm.org <tmoran@acm.org> wrote:
> But with
>    type Rows is new Local_Float;
>    type Cols is new Local_Float;
> the compiler's type checking can point out such errors.  In that case,
> of course, you have to use a record

Sure, my rule wouldn't apply there because we're no longer talking
about a composite of a single element type.

Cohen uses x,y coodinates of different types as an example of over
typing.  I'm kind of on the fence.  I've been declaring every
dimension within a coordinate system to have the same element type
because it seems to be more of a hinderance than a benefit to seperate
them.  The question is whether y is a function of x, which can't
always be answered when the type comes into existence.

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: Records that could be arrays

[Justin Gombos]

On 2006-02-23, Wilhelm Spickermann <zulo.20.unbenutzbar@spamgourmet.com> wrote:
>
> I think it depends on the meaning of "type". The three floating
> point numbers in a polar coordinate system are of three
> different _kinds_ and should be put into a record and not into
> an array -- even if they have the same _type_.

Why?

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: Records that could be arrays

[Justin Gombos]

On 2006-02-23, Jean-Pierre Rosen <rosen@adalog.fr> wrote:
>
> I beg to disagree here. Arrays are for *iterative* structures, if
> you don't have a for loop over an array, it should be a record.

In most cases you don't know at the time you code the type whether
you'll use a loop; and records offer no advantages either way.  While
limitations can be quite useful when they apply to visibility or
access, I see no advantage to limiting the expressive power that
arrays have.

> The fact that all components are of the same type may be an accident
> that changes during program evolution.

Good point.

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: Records that could be arrays

[Wilhelm Spickermann]

Hi,

Justin Gombos wrote:

> On 2006-02-23, Wilhelm Spickermann
> <zulo.20.unbenutzbar@spamgourmet.com> wrote:
>>
>> I think it depends on the meaning of "type". The three
>> floating point numbers in a polar coordinate system are of
>> three different _kinds_ and should be put into a record and
>> not into an array -- even if they have the same _type_.
> 
> Why?
> 

These coordinates are of a different kind as they are used
differently -- all geometric formulas handle them differently.
So it is just a coincidence if they are of the same type and so
I wouldn't draw design decisions from the type alone. 

This becomes also visible in the missing loop statements in
typical polar coordinate operations. And it would be rather
unusual for an array to have a special equality definition while
it is rather normal for a record (phi is "dont care" when theta
is zero -- or AFAIK the other way round in North America).

Wilhelm

Re: Records that could be arrays

[Simon Wright]

Stephen Leake <stephe_on_the_web@toadmail.com> writes:

> But records are deeply embedded in my psyche; these types just feel
> more natural as records than arrays. I guess we need to catch the kids
> in high school, and teach them to use arrays instead of records.

I would certainly go for the record approach. Because in my world it
is rare to the point of non-existence to have structures like this;
there's always some extra component of a different type.

What's the logical difference between (r, theta) and (x, y)? the
former could hardly be treated as an array.

Well, since I personally would make Metres a subtype of Float, ditto
Radians, perhaps there's not that much difference in practice -- but a
world, logically.

Re: Records that could be arrays

[Stephen Leake]

Justin Gombos <rpbkbq.xax.gld@uluv.kbq> writes:

> On 2006-02-23, tmoran@acm.org <tmoran@acm.org> wrote:
>> But with
>>    type Rows is new Local_Float;
>>    type Cols is new Local_Float;
>> the compiler's type checking can point out such errors.  In that case,
>> of course, you have to use a record
>
> Sure, my rule wouldn't apply there because we're no longer talking
> about a composite of a single element type.
>
> Cohen uses x,y coodinates of different types as an example of over
> typing.  I'm kind of on the fence.  I've been declaring every
> dimension within a coordinate system to have the same element type
> because it seems to be more of a hinderance than a benefit to seperate
> them.  The question is whether y is a function of x, 

Or if you want the Cartesian magnitude: sqrt (x**2 + y**2). Or any
other function that involves x and y in a single expression. Like
rotation:

Rotated_Point := (a * Point (x) + b * Point (y), c * Point (x) + d *
   Point (y));

> which can't always be answered when the type comes into existence.

If it's a _point_, we already know about such things. If it's a
genuinely new type, yes, it might be unclear.

-- 
-- Stephe

Re: Records that could be arrays

[Stephen Leake]

Wilhelm Spickermann <zhopi.20.unbenutzbar@spamgourmet.com> writes:

> This becomes also visible in the missing loop statements in
> typical polar coordinate operations. And it would be rather
> unusual for an array to have a special equality definition 

Perhaps it is "unusual" in your experience because you are overly
restrictive in using arrays for such types.

Having said that, I don't think I've ever overridden equality for an
array. But I rarely override equality for any type, so that's not a
good measure.

> while it is rather normal for a record (phi is "dont care" when
> theta is zero -- or AFAIK the other way round in North America).

Right. So if we are using an array to represet these coordinates, we
would override equality for that type.

Ada lets us do that, so there is (by definition :) nothing "wrong"
with it!

Equal rights for arrays :).

I see this as similar to a discussion of implementation for a
container. At a high level, we don't care whether a "set" is implemented
as an array of bits or a list of some sort. At a lower level, we do,
and we ask "what is the implementation that gives the fastest
execution time" or similar questions.

At a high level, a "point" is an abstract object, and we don't care
about the representation. At the low level, we ask "would it ever be
convenient to use a loop to process the elements of this type". If the
answer is 'yes', we use an array.

What I have been saying is that the answer is almost always 'yes',
when you consider operations like Text_IO and AUnit checks.

If we implemented points as limited private types, we wouldn't be
having this discussion. But writing access functions instead of just
using Ada syntax is "obviously" too heavy for points, so we make them
public types. But the priciple still applies; the implementation of
the type is logically separate from the abstract interface of the type.

-- 
-- Stephe

Re: Records that could be arrays

[Randy Brukardt]

"Stephen Leake" <stephe_on_the_web@toadmail.com> wrote in message
news:u8xs2xm0l.fsf@toadmail.com...
> Justin Gombos <rpbkbq.xax.gld@uluv.kbq> writes:
>
> > I noticed this example code in 5.4.4 of the Ada Quality and Style
> > Guide:
> >
> >   type Coordinate is
> >      record
> >         Row    : Local_Float;
> >         Column : Local_Float;
> >      end record;
> >
> >   type Window is
> >      record
> >         Top_Left     : Coordinate;
> >         Bottom_Right : Coordinate;
> >      end record;
> >
> > Would anyone here write something like that?
>
> Yes; Windex has it. Although if I was rewriting it from scratch now,
> I might use an array.

Claw also has types like this:

    type Point_Type is record
        X, Y       : Int;
    end record;

    type Size_Type is record
        Width, Height       : Int; -- Width=X_Size, Height=Y_Size.
    end record;

    type Rectangle_Type is record
        Left, Top,  Right, Bottom  : Int;
    end record;

That's partly because we're matching the Windows definitions for these
types, but also because these "feel" like records to me. I generally only
use arrays when I'm storing a number of identical items with identical uses
(although ordering may matter); "Left" and "Bottom" hardly have the same
meaning or use, even though they have the same type and sometimes need to be
combined.

And its certainly easier to change just one if it isn't an array.

                   Randy.

Re: Records that could be arrays

[Dmitry A. Kazakov]

On Fri, 24 Feb 2006 15:23:51 -0600, Randy Brukardt wrote:

> Claw also has types like this:
> 
>     type Point_Type is record
>         X, Y       : Int;
>     end record;
> 
>     type Size_Type is record
>         Width, Height       : Int; -- Width=X_Size, Height=Y_Size.
>     end record;
> 
>     type Rectangle_Type is record
>         Left, Top,  Right, Bottom  : Int;
>     end record;
> 
> That's partly because we're matching the Windows definitions for these
> types, but also because these "feel" like records to me.

I think that the essential question is whether co-ordinates have the same
type. The rest is a question of language deficiency. In this case an
inability to provide an array interface to a record type (to have
enumerated components), or a record interface to an array (to have named
components.)

It looks logical to choose the same type for all co-ordinates. However for
a teletype display they probably should be different. There is a subtler
question whether absolute co-ordinates and distances should of the same
type. Sort of, whether the relativity theory applies to GUI... (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Records that could be arrays

[Steve Whalen]

Dmitry A. Kazakov wrote:
> ... The rest is a question of language deficiency. In this case an
> inability to provide an array interface to a record type (to have
> enumerated components), or a record interface to an array (to have named
> components.) ...

I'm not sure what you mean by a language deficiency.  If you really
want to address an object as either a record or an array, doesn't
something like this meet your needs?

with Ada.Text_IO; use Ada.Text_IO;
with Ada.Integer_Text_IO; use Ada.Integer_Text_IO;

procedure Redefine is

   type IntRecord is
      record
         FirstInt  : Integer;
         SecondInt : Integer;
      end record;
   type IntArray is
     array (1 .. 2) of Integer;

   RecVar : IntRecord := (FirstInt => 1, SecondInt => 2);

   ArrayVar : IntArray;
   for ArrayVar'Address
     use RecVar'Address;

begin

   Put("First Record Element = ");
   Put(RecVar.FirstInt);
   New_Line;
   Put("Array Element 2      = ");
   Put(ArrayVar(2));
   New_Line;

end Redefine;

Re: Records that could be arrays

[Dmitry A. Kazakov]

On 25 Feb 2006 19:24:32 -0800, Steve Whalen wrote:

> Dmitry A. Kazakov wrote:
>> ... The rest is a question of language deficiency. In this case an
>> inability to provide an array interface to a record type (to have
>> enumerated components), or a record interface to an array (to have named
>> components.) ...
> 
> I'm not sure what you mean by a language deficiency.  If you really
> want to address an object as either a record or an array, doesn't
> something like this meet your needs?
> 
> with Ada.Text_IO; use Ada.Text_IO;
> with Ada.Integer_Text_IO; use Ada.Integer_Text_IO;
> 
> procedure Redefine is
> 
>    type IntRecord is
>       record
>          FirstInt  : Integer;
>          SecondInt : Integer;
>       end record;
>    type IntArray is
>      array (1 .. 2) of Integer;
> 
>    RecVar : IntRecord := (FirstInt => 1, SecondInt => 2);
> 
>    ArrayVar : IntArray;
>    for ArrayVar'Address
>      use RecVar'Address;

(:-)) Is it C or FORTRAN? I thought nobody uses EQUIVALENCE blocks anymore!

No, the above is not an implementation of two interfaces by the same type.
It is two overlapped objects of two different types. The difference, apart
from safety issues, is that you have to do it on per instance basis. To get
it right, you need 1) multiple interface inheritance (this comes with Ada
200Y) 2) abstract array and record interfaces (this does not.)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Records that could be arrays

[Wilhelm Spickermann]

Hi,

Stephen Leake wrote:

> Wilhelm Spickermann <zhopi.20.unbenutzbar@spamgourmet.com>
> writes:
> 
>> This becomes also visible in the missing loop statements in
>> typical polar coordinate operations. And it would be rather
>> unusual for an array to have a special equality definition
> 
> Perhaps it is "unusual" in your experience because you are
> overly restrictive in using arrays for such types.
> 
Thats right; it's no argument, I shouldn't have added the last
sentence. It's just an implication of my preferences of using
records for such structures.

Wilhelm

Re: Records that could be arrays

[Steve Whalen]

Dmitry A. Kazakov wrote:
> ... (:-)) Is it C or FORTRAN? I thought nobody uses EQUIVALENCE blocks anymore!
>
> No, the above is not an implementation of two interfaces by the same type.
> It is two overlapped objects of two different types....

I'm not recommending anyone actually use the 'Address overlay, but it
is in Ada for a reason.  A programmer or designer would have to give me
a REAL good reason for doing anything like this in a production system,
and even then I'd probably say no: pick record or array.

About the only way I'd agree to using such code would be if there were
thousands of lines of code that "wanted" to reference a central data
structure as an array, and thousands of lines of code that "wanted" to
reference the same data as a record, but I don't think I've ever seen
this happen in the real world.

But... You said it was an Ada language limitation that you couldn't use
an array as a record and vice versa.  My point is that if it was really
important to do this, you have the option to do a risky implementation
specific overlay and have the expressive power of both array and record
representations. By doing it like in my example, you are documenting
the risky behavior and documenting that you have verified that the
internal representations of the array and the record are identical at
the bit level. And yes, I WANT this kind of trickery to be on a
variable by variable basis, not for an entire class or type of data.

I don't think I'd want Ada to have a facility to do array and record
overlays beyond what exists (in the example I gave), because to me
arrays and records are NOT synonymous. I can't think of a single "real
world" example where the use of the data and the nature of the data in
the application didn't clearly suggest that either it was fundamentally
an array or a record.

I guess that part of the reason I don't want this feature is because I
agree with with Jean-Pierre Rosen's statement that arrays are really
for iterative structures, so I don't see much need for this since most
of the various types of examples given in this thread are clearly (to
me) more safely and properly defined as records.

I don't know that I'd want to burden the compiler with trying to ensure
that an array and record had bit equal representation clauses either
given or implied before allowing such an overlay.  If equal internal
representation is NOT the case, I'd hate to think of the inefficiency
of a program using both "array style" AND "record style" access code
with the compiler having to do a lot of "conversion" of representation
in order to support the hypothesized "overlay" facility.

Ada compilers have enough to keep straight already. Or at least I don't
see enough utility in such a feature to justify the added complexity.
Of course I may be misunderstanding what array/record overlay facility
you have in mind.

Re: Records that could be arrays

[Dmitry A. Kazakov]

On 26 Feb 2006 18:26:43 -0800, Steve Whalen wrote:

> I don't think I'd want Ada to have a facility to do array and record
> overlays beyond what exists (in the example I gave), because to me
> arrays and records are NOT synonymous. I can't think of a single "real
> world" example where the use of the data and the nature of the data in
> the application didn't clearly suggest that either it was fundamentally
> an array or a record.

Consider a linear algebra library. Aren't matrices arrays? Good. Aren't
sparse matrices arrays? Hmm.

Interface /= implementation. I was talking about array interface. The
implementation of the interface can be any.

> I guess that part of the reason I don't want this feature is because I
> agree with with Jean-Pierre Rosen's statement that arrays are really
> for iterative structures, so I don't see much need for this since most
> of the various types of examples given in this thread are clearly (to
> me) more safely and properly defined as records.

Defined /= declared

> I don't know that I'd want to burden the compiler with trying to ensure
> that an array and record had bit equal representation clauses either
> given or implied before allowing such an overlay.  If equal internal
> representation is NOT the case, I'd hate to think of the inefficiency
> of a program using both "array style" AND "record style" access code
> with the compiler having to do a lot of "conversion" of representation
> in order to support the hypothesized "overlay" facility.

There is no any burden for the compiler, because it is up to the programmer
to implement the interface. There is a definite burden for the language
designers to unify the type system and language syntax.

> Ada compilers have enough to keep straight already. Or at least I don't
> see enough utility in such a feature to justify the added complexity.
> Of course I may be misunderstanding what array/record overlay facility
> you have in mind.

What I mean is:

   type Sparse_Matrix is private array (...) of ...;
private
   type Sparse_Matrix is tagged record ...;
   -- Here the compiler will politely ask me to provide an implementation
   -- of access to element primitive operations of Sparse_Matrix.

or

   type Joystick is private record
      X : Integer;
      Y : Integer
   end record;
private
   task type Joystick is ...;
   -- Here I will be required to provide access to components methods,
   -- which I will implement via rendezvous! (:-))

Ada should finally get ADTs right!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Records that could be arrays

[Robert A Duff]

"Steve Whalen" <SteveWhalen001@hotmail.com> writes:

> Dmitry A. Kazakov wrote:
> > ... (:-)) Is it C or FORTRAN? I thought nobody uses EQUIVALENCE blocks anymore!
> >
> > No, the above is not an implementation of two interfaces by the same type.
> > It is two overlapped objects of two different types....
> 
> I'm not recommending anyone actually use the 'Address overlay, ...

I'm not entirely sure what Dmitry is asking for,
but I'm pretty sure it's not overlays.

> I don't think I'd want Ada to have a facility to do array and record
> overlays beyond what exists (in the example I gave), because to me
> arrays and records are NOT synonymous. I can't think of a single "real
> world" example where the use of the data and the nature of the data in
> the application didn't clearly suggest that either it was fundamentally
> an array or a record.
> 
> I guess that part of the reason I don't want this feature is because I
> agree with with Jean-Pierre Rosen's statement that arrays are really
> for iterative structures, so I don't see much need for this since most
> of the various types of examples given in this thread are clearly (to
> me) more safely and properly defined as records.

Yes, arrays are about iteration.  But there are several features built
in to Ada that "iterate" over record components.  That is, they do
something like "for each component loop...".  Equality of records is
defined in terms of equality of the components.  Finalization is defined
in terms of Finalize on subcomponents.  Stream attributes are defined in
terms of the component attributes.  There's something fishy when a piece
of functionality is available to the language designer, but not the
programmer.

Of course, to make a "for each record component" facility available to
programmers would require some interesting type rules.  The type of the
current component in that loop needs to be some sort of class-wide type
that covers all the component types.  And for the built-in stuff, that's
exactly what happens -- for example, "=" works only when all the
components are non-limited, and therefore have an "=".

I've had cases where there's a hierarchy of 100 or so tagged types,
forming a tree -- each record extension has some components of type
access-to-something'Class.  I'd like to define a Tree_Walk operation
that follows all such pointers, and calls some class-wide Action
procedure.  In Ada 95, it would be generic; in Ada 2005, I'd pass a
"not null access procedure".  It's possible to do that in Ada, but you
have to override a walker method on every type.  That's error prone,
because you have to remember to update the walker every time you add a
record component.  It would be really nice if the compiler could do that
for me -- after all, the compiler knows what all the components are, and
it does something very similar in implementing "=" and streams etc.

One of my favorite features of Ada is that when I write an aggregate
without 'others', the compiler complains if I forgot something.

> I don't know that I'd want to burden the compiler with trying to ensure
> that an array and record had bit equal representation clauses either

How about burdening the compiler with generating code to touch each
component?  Nothing to do with representation.

> Of course I may be misunderstanding what array/record overlay facility
> you have in mind.

Me, too.  ;-)

- Bob