Re: Your wish list for Ada 202X

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:16388p09ph28u$.1mglp0rm7pli9$.dlg@40tude.net...
> On Thu, 10 Apr 2014 17:39:39 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:17twpp4p8u7o$.1idvzaaio4f3t$.dlg@40tude.net...
>>> On Wed, 9 Apr 2014 22:28:36 -0500, Randy Brukardt wrote:
>> ...
>>>>> Ada has no support for dynamic linking anyway, so it is how it is 
>>>>> right
>>>>> now. Introducing MD won't make bad any worse.
>>>>
>>>> MD isn't the problem; preference rules are the problem.
>>>
>>> That requires a proof which shows that no set of rules can exist that
>>> fulfills the requirements X, Y, Z. So far it is word against word. Not
>>> even X, Y, Z is formulated.
>>
>> Actually, there was such a formal proof constructed during the design of 
>> Ada
>> 9x. Unfortunately, that's pretty much all I remember about it, so it's 
>> not
>> much help in this discussion.
>>
>> But it's quite clear that (sane) preference rules cause Beaujolias.
>>
>> Consider an expression node for which two choices (let's call them A and 
>> B)
>> remain after eliminating obvious mismatches. (This situation can be 
>> common
>> when literals are involved, as they match so many types). Ada of course
>> makes the expression illegal in this case, specifically to avoid 
>> Beaujolias.
>>
>> But let's consider a preference rule instead. The rule choses A over B, 
>> and
>> then the program is legal and runs.
>>
>> Now consider adding another operation C in some package that's referenced 
>> by
>> the semantic closure ("with" in Ada) of our expression. Assume that C 
>> also
>> is a possible choice for our expression node. If the preference rule 
>> picks C
>> rather than A (or picks B for that matter), then we have the classic
>> Beaujolias scenario when a legal program does something different because 
>> an
>> operation is added to an unrelated package.
>
> Your example refers to overloading possible for operations on unrelated
> types. I don't see how this is scenario could be possible for a primitive
> MD operation. One of the requirements put on MD is that *all* combinations
> of tags up to the root of the inheritance tree be defined and checked at
> compile time. This requirement automatically precludes appearance of C 
> from
> air. It cannot be primitive and thus the preference rules would not apply
> to it.

Doesn't matter. First, you'd have to prevent adding or removing new 
primitive operations to a hierarchy. That seems like a nasty limitation. 
Second, you can introduce a new primitive operation by withing ["ripple"] or 
using ["Beaujolias"] an existing package that wasn't previously part of the 
client. Introducing an otherwise unused package ought not change the 
behavior of a client.

> This requirement is actually a problem of MD, I don't know how to solve,
> i.e. how to stretch a hierarchy across several packages. Let two packages
> define two types P and Q and a cross operation F between. When in a third
> package R gets derived from P, then how and where we define F for R and Q,
> provided this third package may know nothing about the package of Q.

I suppose if you could actually solve such a problem without introducing 
crazy usage requirements, you could get the same effect as a preference rule 
safely. But I'd guess (and I admit it is a guess) that the problems are 
essentially the same and the fact that one clearly fails the test means that 
the other would clearly fail the test as well.

                                              Randy.