Re: Your wish list for Ada 202X

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

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

It doesn't matter what the preference rule is, one can always construct such 
a scenario. Unless, of course, the preference rule depends on something 
other than the name and type profiles declared in the source code. Using 
temporal information would work, of course, but it would be a nightmare for 
portability, as starting a new project with the same source code would 
change that information and cause the program to run differently. I believe 
that any rule not involving the contents of the source code would have 
similar problems.

The only time a preference rule is safe is if no user can add or delete 
operations for the types in question. That's why it's OK for 
univeral_integer. (It also means that future versions of the language can't 
add or delete operations for universal_integer, which might be a problem 
someday.)

                              Randy.