Re: Proposal: Constructors, Assignment [LONG]

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

Randy Brukardt wrote:

> Dmitry A. Kazakov wrote in message ...
>>Randy Brukardt wrote:
>>> Dmitry A. Kazakov wrote in message ...
>>>>Randy Brukardt wrote:
>>>>> The basic idea is to somehow figure a value of Ada.Tags.Tag, then
> use
>>> it
>>>>> to control dispatching on a function that returns the correct kind
> of
>>>>> object. This requires a special call:
>>>>>
>>>>>       Obj : T'Class := Func (<args>) use Tag_Value;
>>>>
>>>>The question is, will dispatching without an object be useful in
> cases other
>>>>than construction?
>>
>>Why this sort of syntax was chosen?
> 
> I chose it only because it has a natural, cheap, and obvious
> implementation. I was hoping someone would have a better suggestion (but
> that turned out to be "kill the idea").
> 
>>I think more consequently in Ada's
>>spirit would be sort of:
>>
>>   Obj : T'Class (Tag_Value) := Func (<args>);
>>
>>Isn't tag a natural constraint/discriminant of T'Class?
> 
> Yes, but this doesn't work, because you don't know the discriminants for
> the object.

I need not know them. The call to Func has to be dispatching, so the 
function will return all discriminants. It should work exactly as

   Obj : T'Class := Func (<args>) use Tag_Value;

> Indeed, you don't even know how many there are or their
> types (since you can change the discriminants on extensions, including
> adding or removing them), so you can't even give them if you want to.

Yes, so the type T'Class (Tag_Value) should be made indefinite to prevent 
object declarations like:

   Obj : T'Class (Tag_Value);

Or do you think that things like:

procedure Foo1 (X : T'Class) is
   procedure Foo2 (Y : T'Class (X'Tag)) is
      ...

could become a problem?

>>BTW. Why not to allow tag comparisons >, >=, <, <=? I mean:
>>
>>   function ">" (Left, Right : Tag) return Boolean;
>>
>>A>B if B is a descendant of A, but not of A type.
> 
> These certainly are allowed if you write them yourself.

How? I think they should be predefined for all tags along a path in a type 
tree. If they of different paths, Constraint_Error have to propagate.

> Even if you had
> them, you still need a way to control the dispatching based on the
> result (once you've figured out the LCD).

Not always. I have in mind simulation of multiple dispatch for binary 
operations. I could declare one as:

function "+" (Left : T; Right : T'Class) return T'Class;

Should I have "<=" for tags to figure out which argument is closer to T an 
implementation could be very straightforward:

type New_T is new T with private;

function "+" (Left : New_T; Right : T'Class) return T'Class is
begin
   if Right'Tag <= New_T'Tag then
      -- Right is closer to T than Left or same as Left
      declare
         Result : New_T := ...;
      begin
         ... -- Sum a New_T and one of its ancestors
         return Result;
      end;
   else
      -- Right is more closer to T than Left
      return Right = Left; -- Dispatch on Right
   end if;
end "=";

There is a work-around using "in", but it is nasty because it requires a 
hidden parameter to prevent infinite recursion.

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