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.201.168 with SMTP id kb8mr9653156pbc.3.1335730147227; Sun, 29 Apr 2012 13:09:07 -0700 (PDT) Path: r9ni113175pbh.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 22:09:03 +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-29T22:09:03+02:00 List-Id: On Sun, 29 Apr 2012 15:27:10 -0400, Robert A Duff wrote: >>> 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. And if he does not? Library packages declare lots of things they don't use themselves. > If you do proper unit testing, > you'll catch it right away. Here applies another language design principle: anything that can be checked statically has to be. > 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. Yes, it seems that the trend is towards adding orthogonal features, which I don't consider either nice or clean. To me "nice clean" is when features are removed (moved to the library level) replaced by fewer, more general ones. >>> 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. What was wrong with already existed abstract tagged null record ? >>...or causing considerable damage >> (changed semantics of returned limited objects). > > I've never understood your viewpoint on that. The semantics was changed, that is. > 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. I tried, but that is irrelevant. As for constructors, the point, rather a trivial observation, is that you cannot initialize raw memory with a subprogram in a sanely typed way. It is up to you, a language designer, to come up with something else. The working name for that thing is "constructor." Add here a few quite obvious requirements on the design: safety upon inheritance, safety upon exceptions raised in the middle of the process, safety against dispatch on not yet constructed components, safety when some entities are tasks, prevention of explicit invocation. Here you are. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de