Re: What would you like in Ada202X?

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:kl5nkc2s9tsx.61oqe3a9ogra.dlg@40tude.net...
> On Tue, 08 May 2012 22:20:21 +0300, Niklas Holsti wrote:
...
>> I'm sure there are complications to sort out. I haven't thought very
>> long or deep about this. If people are interested in this idea, it would
>> motivate some effort on it.
>
> Second to this! Instead of perpetual hand waving about compatibility and
> imaginary evils of MI, we, Ada community, should consider how to sort the
> mess out.

There is no mess to sort out. MI is evil and the worst thing ever to happen 
to Ada was the inclusion of interfaces in Ada 2005. It is imcompatible with 
Ada's goals of fast running code, and simply shouldn't be allowed at all.

(If I'm starting to sound like "anon" on this, I apologize... ;-)

>> I would like to make the "deepening" derivation as similar as possible
>> to the derivation of enumeration types in
>
> With the problems solved you will get enumeration extension for granted.
> Your proposal rounds about how to generate conversion functions. You can
> generate in-conversion, but cannot out-conversions. The case of plain
> extension has the opposite problem: in-conversions are impossible. But the
> mechanics of all this is same: interface inheritance, delegation of some
> inherited operations to the parent's body composed with a conversion.
>
> Semantically, there always will be some issue with conversions, because 
> any
> non-trivial modification of a type, must break something. If it did not,
> you would use the old type instead. It is not the language business, it is
> up to the programmer to resolve. The language should simply refuse to
> automate suspicious cases forcing the programmer to intervene.

Here I agree with Dmitry (but note that the mechanism he is talking about 
here has nothing to do with multiple inheritance; it works just fine with 
Ada 95 type derivation or something similar to that). It makes more sense to 
allow the programmer to provide the needed conversion functions than to come 
up with special features for doing that.

I designed a straw-man "Root_String" around such conversion functions (you 
can find it in AI12-0021-1), and in fact you don't even need any additional 
Ada facilities to make such a type very usable. You could make it even more 
usable by defining a way to get user-defined slicing and literals (the 
conversion functions alone don't work for literals because of ambiguity 
problems, forcing qualification of all literals would be madness). This 
wasn't vetted by anyone, so take it with a grain of salt...but it 
illustrates the possibilities.

                                    Randy.