Re: What would you like in Ada202X?

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

On Tue, 08 May 2012 02:18:28 +0300, Niklas Holsti wrote:

> On 12-05-07 10:49 , Dmitry A. Kazakov wrote:
>> On Mon, 07 May 2012 00:26:52 +0300, Niklas Holsti wrote:
>>
>>> On 12-05-06 22:28 , Dmitry A. Kazakov wrote:
>>>>
>>>> Yes, for tagged types operations which are unsafe to inherit are inherited
>>>> abstract, e.g. functions returning covariant value.
>>>
>>> The same could be done also for extension by deepening, but it is not
>>> needed, as long as we don't introduce tags and class-wide programming
>>> for these types. Inheriting these operations as abstract could even be
>>> inconvenient, since it would force the program to implement (override)
>>> the operations even when they are not needed.
>>
>> What are you going to do with user-defined operations?
> 
> As distinct from what? Predefined operations? Why should there be any 
> difference?

Because if you inherit them, you get all substitutability problems you
wished to avoid:

   procedure Foo (X : out Message_Kind1) is
   begin
       X := Request;
   end Foo;

But you already answered below than you want to disallow all out and in-out
operations.

>> In the model (1) where the derived type is a subtype (in Ada sense)
> 
> I'm afraid I don't understand, sorry. Are you talking about Ada 
> "subtype" declarations? They are not "derived types" in the Ada sense.
>
> My suggestion for derived enumeration types that extend the parent type 
> (by "deepening") would create derived types (in the Ada sense), not 
> subtypes (in the Ada sense). Thus any user-defined (primitive) 
> operations for the parent type (except those with "out" parameters of 
> that type, as already discussed) would be inherited (redeclared) for the 
> derived type and implemented with automatic conversion of "in" parameters.

This would exclude all functions returning values of the type. In
particular T'Val, T'Succ, T'Pred. Are you going to define some of them new?

>> they
>> get automatically inherited in any context where visible. [This in effect
>> makes you exposed to "class-wide" programming with subtypes even if you
>> don't want to. All subtypes of a type form a class with ad-hoc operations
>> gathered from all members, when visible.]
> 
> Could you give an example, preferably using the types Message_Kind1 and 
> Detailed_Message_Kind?

So far it is clear, except for:

1. Distinction between primitive and non-primitive operations. Are all
in-operations primitive (inherited). E.g.

   package P
       type Detailed_Message_Kind is new Message_Kind1 ...
   end P;

   package Q is
       procedure Baz (X : Message_Kind1);
       ...
   end Q;

   with P, Q; use P, Q;
   package R is
       X : Detailed_Message_Kind;
   begin
       procedure Baz (X); -- Is this legal?

2. Double-dispatch / multi-methods. What happens with operations which have
several parameters of the parent type:

   procedure Set (X : in out Message_Kind1; Y : Message_Kind1);

This is inherited in Y, but not inherited in X. Will it become
contravariant in X? E.g.

   procedure Set (X : in out Message_Kind1; Y : Detailed_Message_Kind);

3. Overriding. If this is the model #2, you can override

   procedure Old (X : Message_Kind1);

   overriding
      procedure Old (X : Detailed_Message_Kind);

Can you? This is also related to the question 1. If you can override, you
have multiple dispatch issue, you need freezing rules, you need primitive
and non-primitive in-operations. If you cannot override you may have the
problem that depending on the some contexts one or another operation is
called (weak typing).

>>> It is even more difficult for Ada
>>> because of the compatibility requirements.
>>
>> On the contrary, it is rather specific extensions which likely are to
>> become incompatible. Generalizations are less problematic, you simply
>> define old constructs in new terms.
> 
> If possible! I fear that the "old constructs" in Ada each have their own 
> small, thorny features, carefully defined, for example to avoid specific 
> kinds of distributed overhead, or to spare some implementor from having 
> to make major changes in his/her compiler. While one could likely make a 
> good approximation of the old features by combining new, fundamental 
> primitives, getting all these small details exactly right would be 
> difficult, and failing there would break compatibility.
> 
> However, it would be nice to see this attempted, sooner or later, and 
> perhaps the incompatibility could be tolerated.

If there are compatibility problems they will show up in the proposals like
yours. Because any of them must be based on very few fundamental concepts,
like type, class, interface etc. (I don't care about language terms RM uses
for them, I do care about the semantics.)

My point is that if these concepts are sound, then only incompatibilities
possible are language bugs (not just flaws, but hard bugs) to be fixed
anyway. I don't buy the compatibility argument. The rest is merely syntax
sugar questions.

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