Re: What would you like in Ada202X?

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

On Sun, 06 May 2012 21:48:00 +0300, Niklas Holsti wrote:

> On 12-04-25 10:47 , Martin wrote:
>> Ok, we don't officially have Ada2012 yet but as no new features are
>> going to be added to it, now seems like a good time to start thinking
>> about the next revision.
> 
> There is a proposal for extensible enumerated types, AI95-261 
> (http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ais/ai-00261.txt), that was 
> rejected (and I don't much like it, either). While reading John Barnes' 
> second part of "Rationale for Ada 2012" in Ada User Journal, for some 
> reason an idea came to me of a different and perhaps better concept of 
> extension for enumerated types. I'm not sure that this would be a 
> worth-while addition to Ada, but here it is, for your pleasure or 
> displeasure, as briefly as I could write it.
> 
> The new concept can be describes as "extending enumerated types by 
> deepening", where the AI95-261 concept is "extending by widening".
> 
> The terms "deepening" and "widening" come from seeing an enumerated type 
> as a classification of some set of things. For example, the messages 
> exhanged in some protocol could be classified in this way, initially and 
> roughly:
> 
>     type Message_Kind1 is (Sign_On, Request, Reply, Sign_Off);
> 
> and some general operations might be written using only this rough 
> classification. AI95-261 proposed the ability to derive a "wider" type 
> with more literals, as in:
> 
>     type Wider_Message_Kind1 is new Message_Kind1 with (Tick, Ping);
> 
> The main problem with this extension by widening is that the derived 
> type, Wider_Message_Kind1, is not a "subclass" of the parent type, 
> because some values of the derived type (the new literals) cannot be 
> converted to (or viewed as) values of the parent type. The derived type 
> can't inherit operations from the parent type, because those operations 
> can't handle the added values.

That depends on the operations. Extension is safe with out-operations.

> AI95-261 suggests to raise 
> Constraint_Error in such cases. Note how this differs from derived 
> tagged types.

Yes, for tagged types operations which are unsafe to inherit are inherited
abstract, e.g. functions returning covariant value.

> It  
> In "extension by deepening", the classification is not widened by adding 
> more literals "at the end", but is deepened, or refined, by dividing 
> some or all of the parent literals into a set of new literals, to give a 
> more detailed classification.
> 
> In the protocol example, we can distinguish different kinds of Request: 
> a read request or a write request, and different kinds of Reply: some 
> data (in reply to a read request), an ack (in reply to a write request), 
> or a refusal (in reply to any invalid request). The derivation syntax 
> could be like this:
> 
>     type Detailed_Message_Kind is new Message_Kind1 with (
>        Request => (Read, Write),
>        Reply   => (Data, Ack, Refused),
>        others  => <>);

[...]
> What do you think?

This looks like plain interface inheritance. You inherit the interface (the
literals of the type) dropping the implementation (encoding). Parent's
operations are inherited per composition with a type conversion.

I always wished to have this mechanism in Ada. Note that instead of
inventing some complicated syntax which purpose is basically to generate
conversion functions (four conversions are needed in most general case),
you should just allow the programmer to define them by himself. This would
also solve Character vs Wide_Character issue.

My opinion is that the language should provide very few fundamental
primitives rather than a forest of special cases. Unfortunately there is a
strong opposition to any move in this direction.

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