Re: Your wish list for Ada 202X

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1cdsyxjzsfgzm.1synpaujysv21$.dlg@40tude.net...
...
>>> Of course The former
>>> would be greatly preferable. This requires yet another feature Ada 
>>> lacks -
>>> interface inheritance. Unbounded_String must drop parent's
>>> implementation/representation and inherit only the interface.
>>
>> That's not the problem at all. (The parent here would have no
>> representation, so there is nothing to drop.)
>
> Unbounded_String will be derived from String, or String derived from
> Unbounded_String. The point is to keep it a hierarchy.

Why? There is no interesting relationship between String and 
Unbounded_String other than the interface (which is inherited from the root 
type). There is no opportunity to share implementations, which is the other 
reason to inherit one from another.

Just inheriting things because something *thinks* they should be related is 
silly. There is no advantage to using String'Class (if such a thing existed) 
rather than Root_String'Class, since all the former does is restrict what 
your subprogram can do; it doesn't add any capability.

(In any case, in my model [which is designed for minimum change to the 
existing Ada language], String, Wide_String, and Wide_Wide_String stay 
untagged array types; they have no relationship to the hierarchy of 
Root_String'Class, possibly other than being defined in conversions.)

> And the real problem
> with all that is that there is more than one vector of inheritance:
> 1. memory management (fixed, bounded, unbounded)
> 2. range (character, wide_character, wide_wide_character)
> 3. encoding (UCS-4, UCS-2, UTF-8, ASCII)

1 and 3 are irrelevant, because they shouldn't have any effect on the 
interface -- they're things that should be totally hidden outside of 
streaming for 3. Perhaps 2 should have some affect on the interfaces, but 
that's easily handled with a second level of abtsract types defining those 
interfaces.

Besides, 1 can totally be defined after the fact with packages. That's the 
model that I'm suggesting. "Unbounded_String" is a container for a 
Root_String'Class type; it adds unbounded memory management to whatever the 
string type does. There is no reason that one has to do that as part of the 
string abstraction.

>> The problem is that Unbounded_String defines operations like
>>
>>       function "&" (Left : Unbounded_String; Right : String) return
>> Unbounded_String;
>>
>> which would be ambiguous with the normal "&" if both String and
>> Unbounded_String had string literals (as they must for Root_String_Type 
>> to
>> work).
>
> No, it is unambiguous, because provided Unbounded_String is a descendant 
> of
> String (or reversely)
>
>   function "&" (Left : Unbounded_String; Right : String) return
>      Unbounded_String;
>
> is a part of the implementation of the MD operation
>
>   function "&" (Left, Right : Root_String_Type) return
>      Root_String_Type;

That doesn't help at all. We still don't know which body to execute when a 
string literal is used, because it matches all string types. You would have 
to qualify all string literals in an MD world, and that's something 
programmers would never tolerate.

>> We can't get rid of these problematical operations -- it would be way too
>> incompatible. So new packages is the only way to go.
>
> You can, and everything will stay compatible if the type system is fixed
> first (MD, MI etc). Within present type system it is indeed unfixable and
> moreover, new packages will likely become as messy as the old ones.

As I said before, I am skeptical that an MD system (even ignoring MI) could 
be implemented efficiently enough to be used in critical operations like 
strings. As soon as you go to MD, the linear tag model has to ba abandoned, 
and some sort of search mechanism used for finding bodies to dispatch to. 
(Why? Consider "&". There are three types involved, at least 15 variations 
of those types [encoding * range; many more if one thinks storage has to be 
involved], giving 15**3 possibilities just for that operation alone. It's 
obviously impractical to store that as a flat data structure, especially as 
most slots will be empty.)

The flat tag dispatching model involves a single index into a tag data 
structure, almost always using a compile-time known offset [only univerally 
shared generics have to do something at runtime, and even that's simple]. 
That adds the cost of just a handful instructions and one or two extra 
memory reads [one to get the tag address, one to get the body address] for a 
dispatching call. That's almost never going to be significant, as it is 
dwarfed by parameter passing and the execution of the body. OTOH, if 
dispatching requires looking in various lookup tables to figure out where 
the body address is, that overhead is substantially more expensive and at 
least potentially begins to be a significant part of call overhead.

It's possible that there are things one could do at link-time to cut such 
overhead (there is for MI, for instance), but that would require an all-Ada 
system (which is a rarity these days). I'm skeptical, but I'm not certain so 
I could be convinced otherwise.

                                Randy.