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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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.236.170 with SMTP id uv10mr14258737pbc.4.1335727630960; Sun, 29 Apr 2012 12:27:10 -0700 (PDT) Path: r9ni113066pbh.0!nntp.google.com!news1.google.com!news.glorb.com!solaris.cc.vt.edu!news.vt.edu!newsfeed-00.mathworks.com!nntp.TheWorld.com!.POSTED!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: What would you like in Ada202X? Date: Sun, 29 Apr 2012 15:27:10 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <3637793.35.1335340026327.JavaMail.geo-discussion-forums@ynfi5> <1qepvaumldb5u.1q8eyzla8dyp8.dlg@40tude.net> <14f21yy6r7n40.v7wdf6rhdgjz.dlg@40tude.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 X-Trace: pcls6.std.com 1335727630 23689 192.74.137.71 (29 Apr 2012 19:27:10 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Sun, 29 Apr 2012 19:27:10 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:YZtGyIJSDe2rIplZhuWmBCAVHdI= Content-Type: text/plain; charset=us-ascii Date: 2012-04-29T15:27:10-04:00 List-Id: "Dmitry A. Kazakov" writes: > That more overloading cannot break existing programs, or else there is a > very serious language design bug. OK, then there's a language design bug. I'm not sure it's serious. >> 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, ... Can't happen. If anybody writes code referring to X, it will be illegal. At that time, there cannot already be any (legal) uses of X. Therefore the problem CAN be fixed (presumably by deleting one of the X declarations, or changing its name). >...a context > maintained by another programmer etc. OK, I admit that the person who adds code referring to X might be confused by two utterly useless X's. Assuming it's a different person. >...It contradicts to the principle of > detecting potential problems as early as possible. I'm all for detecting problems early. But this case doesn't seem like that big of a deal. If you do proper unit testing, you'll catch it right away. Anyway, I said, "no NEED to prevent clashes". You could have a special rule for this case (as Ada already does for homographs), but it's not necessary for a coherent language design. >>> 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. I think that would be true if Ada didn't have implicit hiding. What I'm suggesting is that if you changed Ada to be "everything is overloadable", then you'd also want to get rid of implicit hiding, and THAT's what can cause an incompatibility. >>> 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! > (:-)) I see the smiley, but seriously, I don't see that happening. In fact, ARG desperately wants to design nice clean language features, and it's extremely frustrating when the requirement for compatibility prevents it. That's why it's so much more fun to design a new language. Of course, "nice clean" is somewhat a matter of opinion. >> 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"),... Don't blame that one on ARG. ARG proposed to add non-reserved keywords several times, which would have been compatible, but WG9 (the parent committee of ARG) shot it down every time. >...or causing considerable damage > (changed semantics of returned limited objects). I've never understood your viewpoint on that. You keep talking about "true constructors" or "proper constructors" or something, but you didn't outline your design in enough detail for me to understand. - Bob