Re: Composing sequences (interesting to solve)

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

Victor Porton wrote:

> In article <b06t4c$m4h27$3@id-77047.news.dfncis.de>,
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> Victor Porton wrote:
>> 
>>> See an interesting and yet unsolved by me practical task to solve:
>>> 
>>> I have "elements" of various kinds (Base_Element'Class):
>>> 
>>> type Base_Element is null record;
>>> 
>>> There are many various types of element derived from
>>> Base_Element. Some of these contain accesses to other
>>> elements (which I allocate by "new"), so that this forms
>>> trees.
>>> 
>>> To eliminate access types conversions I decided to limit
>>> myself to use only Base_Element_Access (not accesses to
>>> derived types) (BTW, Is it right design decision?):
>>> 
>>> type Base_Element_Access is access Base_Element'Class;
>>> 
>>> One of the types of elements is "sequence" (it is an ordered
>>> container of elements):
>>> 
>>> type Sequence is new Base_Element with private;
>>> 
>>> I wish to produce sequences (allocated dynamically) by such
>>> the syntax using overloaded function "&":
>>> 
>>> E1 & E2 & E3
>>> 
>>> The question is how to define function "&" so that it would
>>> give the right result (access to one dynamically allocated
>>> sequence) independingly on the number of elements?
>> 
>> I think you should clarify whether A & B creates a new object or just
>> binds A and B. Why an access type have to be returned? It is a bad style
>> and error prone. If you really want heap allocated objects [with
>> reference counting and garbage collection], use handles instead of raw
>> pointers. & have to be defined on both handles and privately, on the
>> objects. It is a bit nasty especially if you want to add some operations
>> to derived elements. If so you have two [bad] alternatives:
> 
> I don't understand your question, A & B should create (on heap) object of
> type Sequence which contains accesses to A.all and B.all . A & B & C
> should create Sequence of three elements etc.
> 
> Consider:
> 
> type Pair is new Base_Element with
>    record
>       First, Second: Base_Element_Access;
>    end record;
>    
> The constructor would be just:
> 
> function Make_Pair(First, Second: Base_Element_Access)
>                   return Base_Element_Access is
> begin
>    return new Pair'(Base_Element with First=>First, Second=>Second);
> end;
> 
> But if I use types themselves, I need:
> 
> function Make_Pair(First, Second: Base_Element'Class)
>                   return Base_Element_Access is
> begin
>    return new Pair'(Base_Element with
>                     First =>new Base_Element'Class'(First),
>                     Second=>new Base_Element'Class'(Second));
> end;
> -- Requires two copying of probably big objects First and Second

From this code I see that you want to copy objects (i.e. create new ones).
A & B creates a copy of A, a copy of B and an object that points to both. It 
is a questionable design. What if A is A1 & A2? Would you make a deep copy 
of it then?

> In fact I allocate these elements once at program's (or a
> subrountine's) lifetime (as these are in fact a part of algorithm,
> being something like a programming language interpretor, not just
> a typical data) and then are going to deallocate all of them at
> once by using scopes, not explicit deallocation. You see that I
> don't need reference counting and garbage collection. So I see no
> need for handles.

And so you probably need no heap allocation, which is used when automatic 
deallocation is undesirable or when the number and types of the objects are 
unknown. There is an obvious rule about pointers: avoid copying objects if 
you use pointers to them.

> Do you now consider it a good style or have an idea how to make it
> better? Do you still think that introducing handles would be useful?
> At least I think that reference counting is a bloating for me.

I am still unsure what you need. Why Pair has to be in Base_Element'Class? 
It looks like a container. Or is Pair something like a tree node? Why do 
not you declare it as:

type Pair
     (  First  : access Base_Element'Class;
        Second : access Base_Element'Class
     )  is new Base_Element with null record;

I suppose Base_Element is limited. (?)

>> 1. Compile-time checkable. Derive new handle types and define new
>> operations on them.
>> 
>> 2. Run-time checkable. Define new operations on the handle type and leave
>> checks to casting.
> 
> The interest case is to make it compile time checkable. (Creating
> runtime check of 'Tag attrs is trivial.)
> 
> You haven't given me a solution. (I suspect that it is even impossible
> in Ada9X.)

I almost sure that you rather have a case of some well-known problem, which 
definitely can be solved in Ada.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de