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: buffer1.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: "Jeffrey R. Carter" Newsgroups: comp.lang.ada Subject: Re: Indefinite Containers of Indefinite Private Types Date: Thu, 6 Aug 2015 13:12:33 -0700 Organization: Also freenews.netfront.net; news.tornevall.net; news.eternal-september.org Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Injection-Date: Thu, 6 Aug 2015 20:10:58 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="ee44d3db9c41f5ad88d7e8e8f0268f05"; logging-data="7766"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1932eycePb9g4Veg6+xj05UZJ9Qx+F8DD8=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 In-Reply-To: Cancel-Lock: sha1:K73sEVNoQnjuaVh3ECWTbzZCoOk= X-Enigmail-Draft-Status: N1110 Xref: number.nntp.giganews.com comp.lang.ada:194686 Date: 2015-08-06T13:12:33-07:00 List-Id: 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 guess I'm beating a dead hippopotamus here. -- Jeff Carter "Facts do not cease to exist because they are ignored." Aldous Huxley 134