Re: Your wish list for Ada 202X

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

On Tue, 8 Apr 2014 18:37:35 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:yl8s1sbhw0lw.1bhypcrvreord.dlg@40tude.net...
>> On Mon, 7 Apr 2014 20:15:10 -0500, Randy Brukardt wrote:
> ...
>>> Mixed operations are not the Ada way of typing.
>>
>> It is Ada's way of SUBtyping. Obviously Unbounded_String and String are
>> related subtypes, promoted to types due to implementation reasons only.
> 
> Obvious to you only. Any single program/subsystem should stick to a single 
> string type. The fact that you can't do that in Ada (unless that type is 
> String) is the bug that needs to be fixed.

I don't understand what you are trying to say. Is it that no program shall
use both Unbounded_String and String or that there must be no String
(Unbounded_String) at all?

>>>>> 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.
>>>
>>> No, not really. Most implementations of Root_String'Class could be shared
>>> amongst string types.
>>
>> That would be very inconvenient. Certainly, less class-wide operations are
>> provided better is the design.
> 
> "In"convinient? Why?

Class-wide operations are inefficient, ambiguous, require type casts (and
thus unsafe).

> And in any case, the whole point is to 
> eliminate the requirement to use a single, specific string type for 
> operations that should be generic (generic in the English, not Ada, sense).

And the whole point of keeping operation primitive is to have its interface
generic and the implementation type-specific.

>> The model where operations are primitive has the decisive advantage that
>> the operation can be inherited or overridden in order to provide a more
>> efficient version.
> 
> That wouldn't improve the performance enough to matter. If there is a 
> problem with this scheme, it's that it could be very inefficient. But that's 
> mostly because of the use of dispatching, and that's required for the goal 
> to be reached (for most of the existing predefined operations to have 
> versions that take/return Root_String'Class rather than String). If we can't 
> reach that goal, there is no point to doing this at all.

There will be no dispatching because types are known statically for most
applications. Secondly, even if dispatching is present it is manyfold more
efficient that dispatching within the class-wide bodies per character
basis, which where your proposal leads.

>>> Moreover, there cannot be automatic sharing of operations; that weakens 
>>> the type system. One only wants to share operations that are explicitly 
>>> intended to be shared; that's the point of declaring packages operating on
>>> Root_String'Class rather than some specific type.
>>
>> I don't understand the term "shared operation."
>>
>> If you don't want to provide an implementation you declare the operation
>> abstract. If you don't want an operation in the class, you move it into 
>> the body. Where is a problem?
> 
> As above, it's too much work to extend a type that requires overridding more 
> than a handful of primitives.

String types are library types. You cannot extend String now, so the use
case you are talking about does not exist.

>>> The majority of operations would take Root_String'Class and thus work
>>> on any object. Ones that don't would have been restricted for some good
>>> reason, and would work as now. What's so hard about that?
>>
>> It does not make any sense to me. Consider the operation Append. Which
>> class does it belong to? Does it act on String? Is the argument UCS-2?
> 
> Append takes two operands of Root_String'Class, and returns an 
> Root_String'Class with the type of its first argument. What's the problem?

Append is a procedure. Modifiers of Unbounded_String are in-place
operations, that is the major use case for having Unbounded_String at all.

>>> No, I'm deriving from an abstract type with no representation. There's a
>>> huge difference.
>>
>> No difference whatsoever. We are talking about interfaces. The interface 
>> of Unbounded_String is not the interface of String.
> 
> That's true, but that's a bug. They *should* be the same; only the runtime 
> behavior should differ (when exceptions are raised and the like).

They should not and cannot. The type String cannot have procedure Append
because String size is contracted to be constant. Immutable bounds is the
major use case of String. Mutable bounds is of Unbounded_String. You cannot
have both "same."

>> When you force a set of
>> types to one class you must drop parts of the interfaces uncommon to all
>> members. This is why single parent will never work for any more or less
>> non-trivial set of types. String types and numeric types are such sets. It
>> is not even worth trying. The result is doomed.
> 
> Possibly, but then programming language design in general is doomed. The 
> only solutions that would work are crazily inefficient.

Everything should work exactly so it does now, but without explicit type
conversions.

>>>>> "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.
>>>
>>> Ada.Strings.Fixed has all of those operations.
>>
>> Append (S, SUNDANESE_LETTER_KHA);
> 
> Yes, that's good. If the underlying type cannot store the letter, 
> Constraint_Error is raised.

Yes! You want weak typing all the way!

In my system the above will be compile error because

1. String does not have Append;

2. String is Latin-1.
 
> As with all tagged types, you trade-off compile-time checking for 
> generality. You can't have both (I know people try, but they are mad - 
> they'll have just as much luck creating a perpetual motion machine).

I can, this what a proper types system is for. If you don't change the type
system you end up with a weakly typed language, which is where Ada sails to
since 2005.

>>>>> 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.
>>>
>>> That doesn't work at all; universal integer only has a preference against
>>> itself. All other types are equal.
>>
>> They will have no literals of their own, in this model.
> 
> They have no literals now, in this model. You're just describing the way 
> things are, and then expect it to work differently.

Yes, a common type hierarchy will make it working differently.

>>> and you'd still have
>>> problems with Wide_Wide_String vs. String.
>>
>> No, because wider literals will go to Wide_String and most wide literal to
>> Wide_Wide_String. The idea is to dissect literals according to the code
>> point planes.
> 
> So the behavior of the program changes when the contents of a string literal 
> changes?

Contents of a literal is the literal itself. That is the meaning of the
word "literal." Yes, if you change the literal the behavior changes.
Compare:

    I : Integer_8 := 100;

vs.

    I : Integer_8 := 100_000;

> No thanks.

After you lumped everything into class-wide operations making it weakly
typed?

>>> They are a prime source of beaujolais effects, which Ada considers
>>> completely unacceptable. (Adding or removing a declaration should never
>>> change a legal program into a different legal program with a different
>>> meaning.)
>>
>> Hierarchies of types are not insulated against each other. You cannot
>> simply add or remove declaration of an operation in the hierarchy. That
>> will lead to changes in the dispatching tables, need to define/override
>> something, if the operation is abstract, which is why freezing rules are
>> here etc.
>>
>> It is the nature of a constraint which is far more important than any
>> "beaujolais effects" - that no dispatch can fail at run-time.
>>
>> All slots of any dispatching table must be statically checked for being
>> either properly inherited or overridden. That *necessarily* requires making
>> something illegal which otherwise would be legal. "No-beaujolais" is a
>> nicety for separate compilation, another is strong typing imperative. I
>> gladly trade former for the latter if necessary.
> 
> In other words, you are willing to weaken Ada's contracts in order to get 
> your supposed "strong typing imperative".

No, it is strengthening of the contracts. You removed beaujolais effects by
weakening the contracts to the point where separately compiled units could
retain their contracts independently. Strengthening may lead to loosing
this property.

> Essentially, in your world, you cannot change a package specification 
> because you cannot know what effect such changes have on clients (clients 
> that you don't know much about).

The effect is exactly known - the clients become illegal. That is the idea
of strong contracts. Instead of keeping clients legal but risking
unanticipated behavioral changes, strong contracts make clients illegal
when there is a possibility of changed behavior. If you can statically
prove that the behavior does not change, there is no need to introduce the
"effect."

> That means that there is no hope for 
> reusable software - the originator of the software has to be able to modify 
> it in order to improve or correct it. If that breaks all clients, then 
> either one can do nothing at all, or people just have to stick to their 
> existing (buggy) versions. Neither is acceptable.

Ada has no support for dynamic linking anyway, so it is how it is right
now. Introducing MD won't make bad any worse.

On the other hand, it is well known that OO interfaces are quite fragile
for dynamic linking with or without MD. But this is another problem, which
must be addressed first, when the type system is OK.

>>> And even if you did, it would be an impracticaly large a data
>>> structure in most cases. (Consider that there are something like 20 
>>> string types in a Root_String'Class model,
>>
>> N is not the total number of related types, N is the depth of the given
>> hierarchy. You will have to map Tag to some dense index in the operation's
>> inheritance path and then go into the array with this index. Raw tag is a
>> poor index.
> 
> But it's all we have. Sure, you can map a tag (this requires a loop, either 
> a brute force lookup or some fancier but much more code-intensive version), 
> but that's going to make dispatching far more expensive. You can't do this 
> mapping at compile-time because what mapping you need depends on the 
> interfaces in use.

I can build a perfect hash at bind/link time when all involved tags become
known.

>>>> (However there are serious problems with implementation of MD which I 
>>>> have no idea how to resolve. MI is much simpler)
>>>
>>> I suppose MI is simpler, but it has a similar problem with tag 
>>> construction.
>>> (At least there is only one dimension for interfaces; full MI would turn
>>> things into a much worse situation, as hidden types would have to be
>>> allowed - and then its possible for a type to have multiple copies of the
>>> same interface.)
>>
>> That is a highly desired effect: to support additive model of inheritance.
>> E.g. additive MI from doubly-linked list element.
> 
> It doesn't work, though, because you have to know *which* copy of the 
> interface you are dispatching through.

Operations will be renamed in order to have it unambiguous. It was always
my desire that Ada would require renaming in all cases when something gets
hidden.

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