Re: What would you like in Ada202X?

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

On Sun, 29 Apr 2012 09:35:30 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>>...One could have a separate name space for unique
>> names.
> 
> I'm not sure what you mean.  Usually "separate name space"
> implies distinguishing which name space you're referring
> to via some syntactic means.

Yes, a certain prefix for example.

>> So the imaginary setup is:
>>
>> 1. X and inner X are unambiguous: not Clash (X, inner X)
>> 2. X hides outer X: Clash (X, outer X)
>> 3. outer X and inner X are ambiguous: Clash (outer X, inner X)
> 
> I'm not sure what you mean.

That more overloading cannot break existing programs, or else there is a
very serious language design bug.

> There's no need to prevent clashes.  If you say:
> 
>     X: constant Integer := 123;
>     X: constant Integer := 456;
> 
> (both in the same scope) then all references to X would be
> ambiguous.  So don't do that.

I see this approach problematic, because ambiguity may stay undetected
until very late, in a context where it cannot be fixed anymore, a context
maintained by another programmer etc. It contradicts to the principle of
detecting potential problems as early as possible.

>> This looks broken already. Ambiguity must be transitive:
>>
>>    Clash (X, outer X) and  Clash (outer X, inner X) => Clash (X, inner X)
> 
> I agree that ambiguity should be transitive, and never meant
> to suggest otherwise.  That is, if you swap inner X and outer X,
> it wouldn't change the ambiguity of complete contexts that
> have visibility on both.

If ambiguity is transitive, then, I have no proof, of course, but my gut
feeling tells me, that it will be impossible to produce ambiguity the way
you described.

>> If not transitive, that must be fixed even if backward incompatible.
> 
> Well, we know you don't care very much about compatibility,

On the contrary, but

1. I also see things rationally. If the language requires 2+2=5, that has
to be fixed even if would break some programs. (There is a hierarchy of
priorities)

2. Compatibility is a handy weapon in the hands of ARG to reject anything
without considering if there will be any compatibility problems actually!
(:-))

> but I assure you ARG would be tarred and feathered if we
> threw compatibility concerns out the window.  And rightly so.
> The Ada 9X team and the ARG already get grumbling about the
> fairly modest incompatibilities that were introduced.

There are plenty examples when incompatibility was introduced with no gain
(e.g. reserving words like "interface"), or causing considerable damage
(changed semantics of returned limited objects).

> But anyway we're not going to get rid of implicit hiding in Ada
> -- way too incompatible.

Nobody seriously considered this, because the problem is way under the
radar of most people who are really capable to design the language. The
purpose of comp.lang.ada is to make them interested... (:-))

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