Re: Looping over a tagged record?

[Charles Hixson <charleshixson@earthling.net>]

"M. A. Alves" <maa@liacc.up.pt> wrote in
news:mailman.993045741.6638.comp.lang.ada@ada.eu.org: 

>> >. . , I was wondering if there is anyway to loop over all
>> >elements in the record, checking their type and then
>> >taking the right action... 
>> 
>> If you really need to do this, you probably should have put
>> the bounded strings into an array inside the record,
>> instead of just making them flat fields. 
> 
> Often I also want to merge record and array i.e. have named
> _and_ iteratable "components". Theoretically this comes down
> to "types as objects", which Ada doesn't have. Practically,
> a "standard" Ada idiom for this is an heterogenous array
> indexed on an enumeration e.g. (not tested): 
> 
>   ...
>   type Field_Ptr is access Field'Class;
>   type Field_Names is (Field_1, Field_2, Field_3);
>   type Record_Type is array(Field_Names) of Field_Ptr;
>   A_Record: Record_Type := (
>     Field_1 => Field_Constructor_A(...),
>     Field_2 => Field_Constructor_A(...),
>     Field_3 => Field_Constructor_B(...));
> 
> Now we have a record-like object A_Record with "components"
> Field_1, Field_2 of "type" A and Field_3 of "type" B. This
> example assumes class-wide programming (including
> dispatching), with (tagged) type Field being the root of
> some derivation class. Iterating over A_Record's 
> "components": 
> 
>   for I in A_Record'Range loop
>     Do_Something(A_Record(I).all); -- dispatching call
>   end loop;
> 
> Accessing "components" by name:
> 
>   Do_Something(A_Record(Field_1).all);
> 
> This particular approach has a notorious shortcoming: field
> types are not checked (Field_Ptr values can reference _any_
> derived type in the class). The remedy for this is left as
> an exercise ;-) 
> 

It has the further shortcoming that one must know in advance 
what kind of thing one is dealing with, rather than letting it 
identify itself.  (My main interest here.)

Currently what I'm thinking of as an answer it a file of fixed 
size blocks, which are addressed via Ada.Direct_IO, somehow I 
need to make them accessible to reading/writing via IO 
statements.  Perhaps this is AdaSockets?  I haven't figured this 
out yet.  I may end up dropping into C to do this bit.  What I 
basically need to do is examine the incoming data and figure out 
how long it is, and then read it into an appropriate Ada 
structure.  (And, if it's larger than one block, which 
collection of blocks it is composed of.)  Also I need to be able 
to go the other direction.  To take a (nearly) arbitrary data 
structure, and write it out to a block, or collection of blocks, 
perhaps not contiguous.  Together with some identifying 
information, so that when I read it back in I'll be able to 
identify what kind of thing I'm reading.  And I'll need to 
maintain an index, etc., so that I'll be able to find it by key 
value.

This part would be relatively straight-forward in C, but so far 
I haven't figured out how to do it in Ada.  So far it's looking 
like everything is going to need to be descendant from some 
particular tagged type (I'll probably call it persistant), which 
will define a few basic methods (read, write, find, etc.)  But 
the answer that I can currently figure out how to do is to 
implement everything but the inheritance in C.  I'm finding this 
quite distasteful, but I don't know what alternatives are 
better.  And figuring out how I can do this in a way that 
doesn't make me rewrite everything whenever a new class is 
described ... 

This is quite annoying.  Every language seems to have some 
weakness in some part of the process.  So far Python is the 
hands-down winner for the store an object and retrieve it part 
of the job.  But it's relatively slow for all the rest.  (Still, 
it's also pretty easy to connect C to, say, SleepyCat DB, so 
that isn't the determining factor.)

The family of languages that make it easy to read objects in 
from disk, and have them be recognized as objects of the 
appropriate type are all relatively slow (because they all use 
interpreters/pseudo-machines).  Once upon a time there was a 
dialect of FORTH (Neon, by Kyria) that had a better choice.  One 
could specify which objects were bound at compile time, and 
which would be determined dynamically.  And in areas where 
everything could be predetermined, it could be compiled 
efficiently (for FORTH), where as when things were dynamic, 
there was an extra layer of indirection.  Unfortunately, they 
killed themselves when they tried to transfer the program from 
the Mac to the PC.  (Too many comittments, and too few 
resources.)  Now I wouldn't say that FORTH was a particularly 
good language in other ways, but that one flexibility almost 
made up for all the deficiencies.

PyAda sounds like one step in this direction.  I do need to 
check into it.  But it seems that this would essentially be the 
same as calling C code from Ada.  (In fact, I rather suspect 
that it is implemented via Swig, in which case there would end 
up being a quintuple language conversion, Ada-> C-> Python-> C-> 
Ada, and it's hard to see how that could be good.)
-- 
Charles Hixson

Copy software legally, the GNU way!
Use GNU software, and legally make and share copies of software.
See http://www.gnu.org
    http://www.redhat.com
    http://www.linux-mandrake.com
    http://www.calderasystems.com/
    http://www.linuxapps.com/