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=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 103376,547e6c7b9fae4e1d X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-01-23 08:18:16 PST Newsgroups: comp.lang.ada Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!nntp-relay.ihug.net!ihug.co.nz!news.compaq.com!paloalto-snf1.gtei.net!denver-snf1.gtei.net!news.gtei.net!coop.net!world!news From: Robert A Duff Subject: Re: Instanciation in a package spec. User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Sender: news@world.std.com (Mr Usenet Himself) Message-ID: Date: Thu, 23 Jan 2003 16:14:47 GMT Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 References: NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Organization: The World Public Access UNIX, Brookline, MA Xref: archiver1.google.com comp.lang.ada:33378 Date: 2003-01-23T16:14:47+00:00 List-Id: "Jean-Pierre Rosen" writes: > "Robert A Duff" a �crit dans le message de news: wccn0lsvth6.fsf@shell01.TheWorld.com... > > "Jean-Pierre Rosen" writes: > > > Since the body of the instance is elaborated at the point of instanciation, the body of the > > > generic has better been elaborated already.... > > > > I understand the *need* for the rule in Ada. But it's still an annoying > > restriction. It's perfectly reasonable to want to export a generic and > > an instance of that generic from the same package. But Ada's > > elaboration model prevents it. > > > If you make the instance a child (and put a pragma Elaborate_Body in the parent's spec), > then it's OK. That sometimes works, but not always. It also requires the client to "with" bits and pieces of the abstraction. That's *sometimes* desirable anyway, but in many cases, you want the client to get the whole abstraction in one with_clause. And you don't want to have extra names polluting the namespace (sometimes you end up needing a name for the child package, *and* names for some stuff inside it). > Of course, you won't be able to use it from the body of the parent, but if you put it > in a visible part, it's presumabely for external use. It's likely for *both* internal and external use. Instead of Elab_Body in the parent, you can put Elab_All(Parent) in the child. Then the parent body can 'with' the child (so long as it doesn't call it during elaboration). But often you want access to the instance in the private part of the parent, so the child idea won't work. For example, the private part has a record component that is of a type declared in the instance. A related problem is that you can't pass a private type to a generic (in the same package visible part where the private type is declared). I understand the reasons behind this rule, but it's still very annoying. - Bob