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,7a3b1c6915ea1273 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.190.99 with SMTP id gp3mr860056pbc.1.1326936946922; Wed, 18 Jan 2012 17:35:46 -0800 (PST) MIME-Version: 1.0 Path: lh20ni198029pbb.0!nntp.google.com!news2.google.com!goblin3!goblin1!goblin.stu.neva.ru!news.tornevall.net!news.jacob-sparre.dk!pnx.dk!jacob-sparre.dk!ada-dk.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: How many Ada compiler bugs are here? Date: Wed, 18 Jan 2012 19:35:39 -0600 Organization: Jacob Sparre Andersen Research & Innovation 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> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1326936944 29204 69.95.181.76 (19 Jan 2012 01:35:44 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 19 Jan 2012 01:35:44 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2012-01-18T19:35:39-06:00 List-Id: "Dmitry A. Kazakov" wrote in message news:e8vqwjo7ify3.htkn2p8qs8lw$.dlg@40tude.net... > On Fri, 13 Jan 2012 18:26:13 -0600, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" wrote in message >> news:11extopcf5hsy.qk7psu30kjrp.dlg@40tude.net... >>>>> BTW, I always wondered why cannot we have multiple parents of a >>>>> package >>>>> in Ada? >>>> >>>> Sounds hugely complicated. >>> >>> Why? The only complicated thing would naming of the files. >> >> Because the parent's declarations are directly visible in the child. If >> there are multiple parents, you'd have multiple scopes of declarations >> directly visible, and we would have to worry about what happens when >> there >> are conflicts. We don't have to do this in Ada today. > > Yes, but I want this feature in other form anyway. I want to have an > ability to fuse several declaration scopes into a package to reuse > obtained > direct visibility scope later. It is quite a problem now that packages > need > large sets of "with" and "use" clauses in front of them as well as > multiple > "use" clauses inside them (for generic instances). This stuff is repeated > over and over again, which is a maintenance problem and a problem for the > reader. I agree with you, and in fact we tried to provide such a feature in Ada 2012. (See AI05-0135-2.) We eventually gave up, mainly because any scheme for managing the conflicts caused unacceptable problems in maintenance. >> 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.] 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). > 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. 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. I made a proposal to allow overloading of objects (only), which I believe could in fact be done compatibly, but it went nowhere. And there still would be problems with exceptions and packages and types (none of which can be overloaded currently or in any compatible way), so its probably not enough. Randy.