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!mx02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Indefinite Containers of Indefinite Private Types Date: Fri, 7 Aug 2015 14:49:03 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1438976945 20295 24.196.82.226 (7 Aug 2015 19:49:05 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 7 Aug 2015 19:49:05 +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 Xref: news.eternal-september.org comp.lang.ada:27387 Date: 2015-08-07T14:49:03-05:00 List-Id: "Jeffrey R. Carter" wrote in message news:mq0f0g$7im$1@dont-email.me... > On 08/06/2015 11:49 AM, Randy Brukardt wrote: >> >> That's one possibility. We could call it a generic private type. Oops -- >> that name is taken, and alternative names are annoying. (The idea of >> course >> would be similar to the generic incomplete type; the restrictions on the >> use >> of a private type would be enforced on the uses of the generic formal >> type.) >> >> We've also looked at declarations (maybe an aspect) for the generic as a >> whole, there was a proposal for a "forward" declaration for the generic >> (that is, you'd be able to separate the visible part of the generic from >> the >> actual instance, just like in other kinds of packages), and a proposal to >> change the freezing to be exactly like a macro (meaning a break in the >> contract model, and a horror to implement on top of that). We also found >> that there is a workaround of sorts using a child package to hold the >> instantiation, which works so long as the private type doesn't use >> something >> from the instantiation (usually a cursor for a container) in its full >> declaration. The existence of the workaround lowers the priority of >> finding >> a fix, and given the difficulty of doing so, we pretty much gave up. I'm >> sure we'll revisit it someday. > > I looked at some of the AIs you mentioned and saw there were a number of > ideas. > The child-pkg workaround involves using an access type, so it doesn't seem > to > gain anything over using access types directly, and is less attractive > than > access-free noise, which seems to me to be another work around not > considered in > the discussion I looked at. > > The problem seems to be that there is a single instantiation for both the > spec > and body, and the body occurs and is elaborated immediately at the point > of the > instantiation. Another language might instantiate the spec and body > separately, > allowing the body to be instantiated after the full type. There were some > suggestions in the AIs along that line, but couched in terms of delaying > freezing rather than separation of spec and body. > > Maybe something like > > package P is > type T (<>) is private; > private > package Lists is new Indefinite_Vectors > (Index_Type => Positive, Element_Type => T) > with not body; > > type T is record > List : Lists.Vector; > end record; > end P; > > package body P is > package body Lists is new Indefinite_Vectors; > ... I had suggested something along this line (not exactly this, though), but at least some people were trying to do this without making any work for the client. But of course that causes incompatibilties; which led to arguments about how important the incompatibilities are, and that tends to lead nowhere. > I guess I'm beating a dead hippopotamus here. Yup. Randy.