Re: Composing sequences (interesting to solve)

[porton@ex-code.com (Victor Porton)]

In article <b09atk$n7ro0$1@id-77047.news.dfncis.de>,
	"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> Victor Porton wrote:
> 
>> In article <b06t4c$m4h27$3@id-77047.news.dfncis.de>,
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> Victor Porton wrote:
>>> 
>>>> 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;
>>> 
>> 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?

Reversely, I want to not copy these as copying would probably slow 
things down. I just shown that if I would not use access types as 
constructor functions arguments I would need to copy the objects.

> 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.

I want heap allocation by another reasons:

1. Class wide objects cannot be parts of a record. So I need to 
allocate these by "new".

2. I see in Ada no natural and yet efficient syntax for creating trees 
(see below) by constructors with syntax like "A(A(X,Y), B(Z))" without 
using heap allocation.

> 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;

Exactly, I construct a tree (or, more generally, it will be probably a 
directed graph). Objects of type Base_Element'Class are tree nodes. 
Pair is a node with two subnodes.

In fact these trees are representation of programs in some programming 
language.

Do I undersood you correctly that you suggest to use access 
discriminants instead of access fields. I see no advantages of 
discriminants over fields in my case.

> I suppose Base_Element is limited. (?)

No, but probably in a future version it will be limited.

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

Let's forgot about of my original problem and discuss constructing and
deallocating trees (or directed graphs) in Ada. Ideologically the best
solution would be to use controlled types with reference counting or
like for full automation, but I want also efficiency.