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: Intervention needed? Date: Mon, 1 Apr 2019 16:29:27 -0500 Organization: JSA Research & Innovation Message-ID: References: <87wokhk289.fsf@mid.deneb.enyo.de> <87va01gv3t.fsf@mid.deneb.enyo.de> Injection-Date: Mon, 1 Apr 2019 21:29:27 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="24978"; 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; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader01.eternal-september.org comp.lang.ada:56038 Date: 2019-04-01T16:29:27-05:00 List-Id: "Florian Weimer" wrote in message news:87va01gv3t.fsf@mid.deneb.enyo.de... ... >> Personally, I don't think it is possible to meet the goals for efficiency >> without aliasing -- one would have to eliminate things like by-reference >> parameter passing and techniques like lookup indexes to avoid aliasing. > > It might be sufficient to check for aliasing when passing parameters > and raise Program_Error. ??? The parameter itself is the problem. Any call would have to raise Program_Error in such a case. The only way to make such a check that wouldn't trigger all of the time would require looking at both the body and the call at the same time -- a complete abandonment of privacy and separation of concerns. The problem in your example is the object with mutable discriminants. As soon as those exist, it's very difficult to prevent such problems. The "obvious" solution is to ban such types, or ban (as is done for renames) passing any such components as parameters. Neither would be remotely compatible or possible for Ada. In any case, I don't see discriminant-dependent components as having anything to do with violating the type model. You seem to expect more out of the type model than I do! This is just one of many ways to cause erroneous execution in Ada. A "perfect" language would have no such ways, but those are allowed in Ada as a compromise between perfect checking and performance. Randy.