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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Is this a bug? Date: Fri, 3 Jan 2020 18:42:36 -0600 Organization: JSA Research & Innovation Message-ID: References: <1d96e0e1-7700-4947-9fcb-051a1203c703@googlegroups.com> <8bc80421-29fb-4f19-baf0-b14680a99c32@googlegroups.com> Injection-Date: Sat, 4 Jan 2020 00:42:36 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="8782"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader01.eternal-september.org comp.lang.ada:57788 Date: 2020-01-03T18:42:36-06:00 List-Id: "Dmitry A. Kazakov" wrote in message news:qumug8$1bsj$1@gioia.aioe.org... > On 2020-01-03 08:35, reinert wrote: ... >> But what is really the problem of prohibiting to include above: >> >> function a(x: rec1_t) return Integer is (5); >> >> ? >> >> This is similar to that the following is not legal: >> >> type rec1_t is tagged record >> a : Integer := 2; >> b : Integer := 2; >> a : Integer := 5; -- is not legal. >> end record; >> >> ? > > Yes, but that is was not possible, because in Ada 95 the function "a" did > not conflict with members. The change in Ada 2005 introduced dot notation > and thus the conflict. It also doesn't really fix the problem unless one starts breaking privacy. It's not just direct local declarations that cause problems, but also inherited routines and class-wide routines associated with ancestors. And since components can become visible at later points, you can also have something that is legal in a specification be illegal in a body (especially possible for child units). For instance, if you have something like: package P is type Root is tagged private; function C1 (A : Root) return Boolean; function C2 (B : Root'Class) return Boolean; private type Root is tagged record C3 : Natural; end record; end P; Then, for Obj : Root; Obj.C1 and Obj.C2 are legal. package P.Child is type New_Type is new Root with record ??? : Natural; end record; function C3 (A : New_Type) return Boolean; -- Nope. end P.Child; New_Type cannot have components named C1 or C2, so if ??? has either of those names, it has to be illegal. In addition, the function has to be banned because the component C3 will be visible in the body of P.Child. (??? is illegal if it is C3.) Because of the cases illustrated above, you also now have much more significant maintenance problem. Imagine that P is some package out of your control, like a GTKAda or even an Ada.Container package. As Ada stands, one can add a subprogram to a package without having too worry much about incompatibility. Conflicts are possible, but only matter if the entire profile of the new subprogram matches. In cases like this, *any* matching causes problems. That's because objects aren't overloadable in Ada, so a component conflicts with any subprogram with the same name and prefix parameter. One can imagine making objects overloadable in Ada to avoid this problem (the language would probably have been better if that had been the case), but that can lead to the worst possible incompatibility: a program that compiles and means something different than it does in current Ada. To avoid that, you have to have some additional complex rules. And, of course if this was done, we don't need the original rule at all (just let true conflicts happen). So we're pretty much back where we started from. In a language designed from the ground up to have this sort of prefix notation for functions, there'd be no problem. But Ada isn't that language. Randy.