Re: Your wish list for Ada 202X

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

On Fri, 18 Apr 2014 22:10:50 +0300, Niklas Holsti wrote:

> (Apologies for a delayed reply.)
> 
> On 14-04-14 00:07 , Dmitry A. Kazakov wrote:
>> On Sun, 13 Apr 2014 22:43:47 +0300, Niklas Holsti wrote:
>> 
>>> On 14-04-12 11:20 , Dmitry A. Kazakov wrote:
>> 
>>>> I don't deny
>>>> existence of the problem. I am against the solution, which is inherently
>>>> unsafe and constraining (precludes by-copy semantics).
>>>
>>> But class-wide operations which contain dispatching calls also preclude
>>> by-copy semantics, don't they?
>> 
>> Not at all. There is no problem for a class-wide operation to act on
>> by-copy types.
>> 
>> A by-copy class-wide object is a tuple (tag, type-specific value). Upon
>> dispatch the value is passed copy-in/copy-out to the type specific
>> operation.
> 
> OK, but from the implementation point of view, that form of by-copy
> passing could be used for all operations of a tagged class, whether
> class-wide or primitive, with or without redispatching. So it is not
> evident why you said earlier that redispatching prevents by-copy semantics.

Re-dispatching presumes the same object. For by-copy objects a conversion
of T to T'Class would produce a new object on which dispatch would happen.
It would make no sense to call this re-dispatch.

But more importantly is that "re-dispatch" will always dispatch to the
operations of the manifested type. I will consider this in details below.

> If I may guess, your reasoning is perhaps that if we have a tagged type
> T, and a derived type TT with added components, and a primitive
> operation Foo on T which is inherited by TT and uses by-copy semantics,
> then calling Foo on a TT object X should really copy only the T part of
> X, and therefore Foo could not execute a redispatching call to some
> operation Bar on T which is overridden for TT, because the conversion
> T'Class(X) in the redispatching call would have no way to (re)generate
> the TT components of X, because they were not copied.
> 
> I think that argument is wrong from the formal point of view, because
> when Foo is inherited from T to TT, the inherited operation formally
> acts on TT, therefore the by-copy passing would copy all of X, including
> the TT components.

Consider this:

   type T is non-tagged null record;
   procedure Foo (X : T);
   procedure Bar (X : T);

   type TT is new T with record
       I : Integer;
   end record;
   overriding procedure Bar (X : T);

   procedure Foo (X : T) is
   begin
       T'Class (X).Bar;
   end Foo;

   O : T'Class := T'(null record);

   O.Foo;

The representation of O is (T'Tag, null record). When it dispatches on O to
Foo, T'Tag is stripped away and null record is passed to T's Foo. Within
Foo X has the representation null record, *always*. When X is converted in
Foo to T'Class, the result is (T'Tag, null record), because the type of X
is declared as T. When it dispatches on the result Bar, it is T's Bar that
is called, always, because the tag is T'Tag.

As you see, there is no re-dispatch possible with by-copy semantics.
Re-dispatch requires:

1. by-reference semantics (no new objects)

2. extension (parent representations stored within derived objects)

3. embedded tags (class-wide and type-specific representations to be same)

> Another case that comes to mind is an explicit call to the original (not
> inherited) form of Foo, using a call with a conversion of the form
> Foo(T(X)) where X is of type TT. Here, there is more reason to feel that
> by-copy passing should copy only the T part of X (or, rather, the
> conversion should return only the T part of X), and then redispatching
> from Foo would indeed be impossible. But if T(X) is seen simply as a
> view conversion, not a value conversion, then X could still be passed
> by-copy using your (tag, type-specific value) form.

It is the tag in the pair (Tag, Value) which determine the type of Value.
You cannot use T'Tag with TT value, that is inconsistent.

>>> A class-wide operation, in my view, is just like a primitive operation
>>> except that (1) (re-)dispatching is implicit and automatic for all calls
>>> to primitive operations of the parameter object (because the parameter
>>> is a class-wide type) and (2) the operation cannot be overridden.
>> 
>> There is no re-dispatching in a class-wide operation. It is defined on
>> class-wide objects, so it simply neither dispatch nor re-dispatch.
> 
> Huh? If a class-wide operation calls a primitive operation, using a
> controlling parameter of the class-wide type, that is certainly a
> dispatching call.

Yes, but this is a call to some different operation. I thought you were
talking about the class-wide operation itself. This operation does not
[re-]dispatch. What happens in its body is a different issue.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de