Re: Composing sequences (interesting to solve)

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

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

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.

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.

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