From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,81bb2ce65a3240c3 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.213.106 with SMTP id nr10mr14004551pbc.2.1335715175889; Sun, 29 Apr 2012 08:59:35 -0700 (PDT) Path: r9ni112519pbh.0!nntp.google.com!news2.google.com!goblin1!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: What would you like in Ada202X? Date: Sun, 29 Apr 2012 17:59:33 +0200 Organization: cbb software GmbH Message-ID: References: <3637793.35.1335340026327.JavaMail.geo-discussion-forums@ynfi5> <1qepvaumldb5u.1q8eyzla8dyp8.dlg@40tude.net> <14f21yy6r7n40.v7wdf6rhdgjz.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: Gbl624r6iuNIccy3ASy5ag.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: 2012-04-29T17:59:33+02:00 List-Id: On Sun, 29 Apr 2012 09:35:30 -0400, Robert A Duff wrote: > "Dmitry A. Kazakov" 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