Re: Records that could be arrays

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"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