Re: Your wish list for Ada 202X

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

On Wed, 2 Apr 2014 17:39:06 -0500, Randy Brukardt wrote:

> "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).

The relationship is that you can mix Unbounded_String and String in
operations like "&".

> There is no opportunity to share implementations, which is the other 
> reason to inherit one from another.

Most of implementations of String can be shared by Unbounded_String. This
is what people do manually all the time converting Unbounded_String to
String and back.

> 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.

You have just said that constrained types are useless. What is the
advantage of using String (1..80). It does not add any capability...

>> 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.

Presently 1-3 are exposed, and I don't understand how you are you going to
hide them:

   type A (Length : Positive) is record
       X : String (1..Length);
   end record;

   type B is record
       X : Unbounded_String;
   end record;

Looks a quite visible difference to me.

> Besides, 1 can totally be defined after the fact with packages. That's the 
> model that I'm suggesting.

This is equivalent to deriving from fixed string, which is the common
denominator. 

> "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.

But then you necessarily loose all operations String cannot have, e.g.
Append, Replace, etc. The idea is of course that Unbounded_String,
Unbounded_Wide_Wide_String, Unbounded_UTF8_String share this interface.

>>> 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 are mixing different issues. As I said, there is no ambiguity in "&".
Literals is a completely different case. They are ambiguous already.

> You would have 
> to qualify all string literals in an MD world, and that's something 
> programmers would never tolerate.

Ambiguity of literals can be resolved using preference rules like ones
invented for Universal_Integer. We could introduce Universal_String etc.

Another method could be making Latin-1 literals contravariant String, i.e.

package Dont_Make_Me_Primitive is
   function "A" return String;
   function "AB" return String;
   function "ABC" return String;
   ...
end Dont_Make_Me_Primitive;

not inherited by Unbounded_String, Wide_String etc. That will introduce
desired preference.

And, yes, you will be able to assign "ABC" to Unbounded_String because ":="
is a MD operation with one body dealing with that:

   procedure ":=" (Left : in out Unbounded_String; Right : String);

Otherwise, yes, preference rules are necessary to resolve

   A & B & C

Between

   String'(A & B) & C

and

   Unbounded_String'(A & B) & C

>>> 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.

An MD operation needs an N-D array indexed by tags of controlling
arguments. Dispatching is indexing the array.

(However there are serious problems with implementation of MD which I have
no idea how to resolve. MI is much simpler)

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