Re: Your wish list for Ada 202X

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

On Mon, 31 Mar 2014 18:55:07 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:8bhozh836pyt$.1qctlysud0s2q$.dlg@40tude.net...
>> On Fri, 28 Mar 2014 16:27:09 -0500, Randy Brukardt wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:o4o5ao9k7hz9.l7ebk8qxfv32.dlg@40tude.net...
>>>> On Thu, 27 Mar 2014 16:50:20 -0500, Randy Brukardt wrote:
>>> ...
>>>> Real issue: Multi-methods (String vs String) and full multiple dispatch
>>>> (String vs Character)
>>>
>>> That's an alternative, but the question is whether that can be implemented
>>> with less overhead than the scheme I suggested. I believe the answer is no,
>>> at least within generalized string packages (which hopefully will become 
>>> the norm for new string operations in Ada).
>>
>> If and only if the generalized packages would define operations class-wide.
>> The idea is to rather make them primitive operations, so that a vendor (if
>> he wanted to) could provide type-specific implementation for the cases of
>> major interest, e.g.
>>
>>   overriding function "&" (L, R : String) return String;
>>
>> instead of inheriting (covariantly) ineffective parent's
>>
>>    function "&" (L, R : Root_String_Type) return Root_String_Type;
> 
[...]
> So, of course each type will define useful primitive 
> operations, and all of the root string operations will be primitive.

In that case there will be no overhead when an operation is overridden.

> It's not a question. There's no way to do that because the operations 
> already defined for Unbounded_String would make it ambigious if given string 
> literals (and all Root_String_Type'Class types would have string literals). 
> It would be completely unusable.

When you inherit from a type you "define" inherited operations. It is not
ambiguous since operations are primitive. So long there is no overloading
there will be no ambiguity.

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

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

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