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,7a3b1c6915ea1273 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.189.72 with SMTP id gg8mr1929078pbc.4.1326969251060; Thu, 19 Jan 2012 02:34:11 -0800 (PST) Path: lh20ni199428pbb.0!nntp.google.com!news1.google.com!goblin1!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: How many Ada compiler bugs are here? Date: Thu, 19 Jan 2012 11:33:58 +0100 Organization: cbb software GmbH Message-ID: References: <01dd6341-9c3c-4dcb-90f8-6ac66c65eb66@z1g2000vbx.googlegroups.com> <98adc34c-deed-4190-9e10-755cb886984f@n39g2000yqh.googlegroups.com> <5cm1d9xlavps$.1tjtc88r9ze21$.dlg@40tude.net> <6d352870-d204-4137-a562-5a0b67db1f80@h13g2000vbn.googlegroups.com> <15d37z3l8zllg$.3z2pj9cy5kvq.dlg@40tude.net> <7610c0ee-db98-4530-afab-f29e187ee7d0@h3g2000yqe.googlegroups.com> <1swdtf9umcv6h.1abrhg4hr4tdd$.dlg@40tude.net> <189376d3-eab5-44a2-a7fc-8a227d1f6d70@k10g2000yqk.googlegroups.com> <11extopcf5hsy.qk7psu30kjrp.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.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-01-19T11:33:58+01:00 List-Id: On Wed, 18 Jan 2012 19:35:39 -0600, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:e8vqwjo7ify3.htkn2p8qs8lw$.dlg@40tude.net... >> On Fri, 13 Jan 2012 18:26:13 -0600, Randy Brukardt wrote: >> >>> There is a similar problem for package use clauses, but there is no >>> satisfactory solution to that problem. All of the solutions are dangerous >>> (Ada picks the least dangerous solution, but it still has lots of issues in >>> practice). I don't think we want more of these cases. >> >> I am not sure which solutions you have in mind. I would simply forbid any >> conflicts. The compiler must insist on explicit renaming of all >> conflicting entities. > > We tried rules on that line, but they caused the sorts of maintenance > problems that aren't really acceptable. It should never be the case that > adding a declaration to a package makes some other package illegal even > though the other package does not use the new declaration. (Yes, I know > there are cases where direct visibility and parent visibility violate this > principle, but just because the language is already wrong doesn't mean it > should be made wronger. :-) > [Keep in mind I'm talking about an *addition* and not a modification of a > declaration. The principle is that adding new features to a package > shouldn't cause clients that don't use those features to need modification.] This goal is unreachable in principle. It is the same delusion as behind the LSP. There is not such thing as safe extension or addition, alas. That should not hinder use of addition (in either form of a subtype or an extended package). > Another cause of problems was diamond inheritance, where an integrated > package tries to add a declaration that is already directly visible by some > other path. We definitely don't want those to conflict, but it is very hard > to craft rules that have the right effect (in large part because visibility > is based on "views", not "entities", and these clearly are different views). Yep, that must be fixed. It must be clear where the semantics is referential and where it is not. Presently it is so as if there were no difference, but this concept is clearly not maintainable anymore. >> It is rather a perceived problem so long declaration scopes cannot be named >> an reused. Once we would use them as named entities, construct and design >> them intentionally, the problem would disappear. > > Maybe, but the evidence is that handling the conflicts is a major > maintenance problem. Right, that is why we have to address this. In particular to flag conflicts as errors rather than letting them slipping through the layers of packages to the point where there is no easy way to fix the problem. Early error detection is the Ada's strength. If we had means to design declaration scopes, then instead of patching conflicting packages, we could create an integration package which would resolve conflicts and use that package instead of both. > One thing that clearly would help would be to make all entities > overloadable. In that case, there would be far fewer conflicts (objects > would overload on their types, and could overload with functions and > procedures as well), so perhaps we could live with the conflicts. But that > would be hugely expensive in existing Ada compilers (pretty much all of the > visibility mechanisms would have to be redone from scratch), and it is > unlikely that it could be done compatibly with existing code. We, the programmers, do not care. That is your problem! (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de