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!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!v102.xanadu-bbs.net!xanadu-bbs.net!nntp.club.cc.cmu.edu!micro-heart-of-gold.mit.edu!newsswitch.lcs.mit.edu!nntp.TheWorld.com!.POSTED!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: 'Protected' abstract subprograms Date: Wed, 15 Jan 2014 19:51:31 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <839fee13-2743-49f6-a7f3-f95578386201@googlegroups.com> <1aav8alqsnqqv.5urmifgwh1mv.dlg@40tude.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls7.std.com 1389833492 31880 192.74.137.71 (16 Jan 2014 00:51:32 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Thu, 16 Jan 2014 00:51:32 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:INXZA8+5Ue/qZC52unRbyU1c4Hw= Xref: news.eternal-september.org comp.lang.ada:18193 Date: 2014-01-15T19:51:31-05:00 List-Id: "Randy Brukardt" writes: > But Adam's point still holds: with enough ability to qualify the actuals, > these rules aren't needed. Sure. And my point was that without a complete change in the way generics work, that would require dozens of additional contractual specifications. > I forget the exact case, but I recall something like that fairly recently -- > we wanted to require some property to match on generic formals, but then > many generics would have to be duplicated in order that they would work both > with and without that property. (Was it predicates? Can't remember anymore.) > To really get proper working, you have to have "with property", "without > property", and "don't care about property", but of course the latter brings > up the legality issues again. I'm not sure what property you're referring to, but "limited" is such a property. E.g., you'd like to have Ada.Containers.Vectors contain a Vector type that is limited if and only if the element type is limited. It works for arrays, but it doesn't work for vectors. There are other cases like that -- e.g. you'd like to be able to say that Vector is derived from Sortable if and only if the Element_Type has relevant comparison ops. > In any case, when I was talking about Ada taking privacy seriously, I wasn't > thinking about (or caring about) generic instantiation. There is no real > privacy for generic specifications, nor can there be (at least with the > model of instantiation that Ada uses). [After all, Ada essentially has > special rules for the meaning of Legality Rules in generic units - those > override all other language principles, whether or not that is a good idea.] > Privacy only really matters for concrete things like packages or instances > of generic packages. Right. That's (part of) why I think the macro expansion model is wrong. We pretend that the instance is actually there, and complain about illegalities in its private part, as if those are the fault of the person who wrote the instantiation (when in fact, that person did NOT write that private part). > My point was that that doesn't allow pricavy breaking (for Legality Rules) > within normal packages. I can't think of any exceptions to that - there > probably is one that I've forgotten but I doubt it invalidates the point. The only case I know of where the code in a package private part can affect the legality of code outside that package is this: package Recursive_Types is type T1 is private; package Nested is type T2 is private; private type T2 is record X: T1; end record; end Nested; private type T1 is record Y: Nested.T2; -- Illegal! end record; end Recursive_Types; You're not allowed to have two records that are mutually recursive like that. So the legality of T1 depends on the code in Nested's private part. But one might argue that this case doesn't count, because there's no separate compilation here. You can't get this effect if Nested is changed to a library unit. - Bob