Re: Your wish list for Ada 202X

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

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

I don't understand how you are thinking the class-wide operations would work 
if everything isn't primitive. That's the only way for an Ada class-wide 
type to even be useful. So, of course each type will define useful primitive 
operations, and all of the root string operations will be primitive. 
(Indeed, the language definition already makes that so in the case of "&".)

> Root_String_Type would be an equivalent of Wide_Wide_String or UTF8_String
> or any other full Unicode character set string.

"Root_String_Type" would be abstract, and the other types would be derived 
from it. New types corresponding to each interesting representation would be 
defined. The existing types would still exist but be obsolescent.

...
>> Right, but that manifests itself in duplicated and overly restrictive
>> packages, which would have to be reworked in order to use a more general
>> interfaces. (Ada.Strings.Bounded and Ada.Strings.Unbounded in particular
>> have overloaded operations that would make everything ambiguous if not
>> eliminated.)
>
> If all string types are members of single class, then all corresponding
> overloaded operations are primitive operations on the class. Overloading 
> of
> overridden operations in guaranteed unambiguous. That is when you build a
> new hierarchy of string types.

Yes, of course, this is what I've proposing.

> Whether Unbounded_String should become a member of this new hierarchy or 
> be
> replaced there with a new type is another question.

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.

As such, all new types is the only possibility. That's what makes this idea 
politically messy.

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

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). Indeed, that's the only reason that Ada doesn't have a way to define 
string literals for a private type -- we talked about it years ago but 
determined that it cannot be used with any of the existing string packages. 
As such, it would have been a weird thing to define.

We can't get rid of these problematical operations -- it would be way too 
incompatible. So new packages is the only way to go.

                                  Randy.