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!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Is there a reason System.Storage_Pools isn't Pure? Date: Wed, 19 Apr 2017 09:37:31 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <178b6fbc-229b-49fc-8ffb-a5797bfc335f@googlegroups.com> <61e151c1-9fe6-4d32-8f13-d425bc41a616@googlegroups.com> NNTP-Posting-Host: vZYCW951TbFitc4GdEwQJg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:46595 Date: 2017-04-19T09:37:31+02:00 List-Id: On 19/04/2017 01:42, Shark8 wrote: > On Tuesday, April 18, 2017 at 12:32:34 PM UTC-6, Randy Brukardt wrote: >> Originally, it was not Pure because it was a child of System, which was not >> Pure. So I can't find any discussion of the merits. >> >> However, Pure packages are automatically Remote_Types packages (that is, >> values of the type can be transmitted between partitions). We'd never want >> that to be the case with a storage pool, so there doesn't seem to be any >> point in it being Pure. > > Are we sure we'd never want that? > I imagine that would be an interesting way to do VMs -- essentially > transmitting the [contained] memory directly between partitions, right? No, so long you don't know what is in the memory. Even considering the case of a shared [distributed] memory pool it cannot be pure. E.g. initialization of an object in the shared memory must be done only once, which does not preclude binding of each shared copy/view, like mapping pointers since copies may be located in different virtual address spaces. > What about a usable-for-anything holder? Huh, what about fixing initialization/fixed in the first place. We would not need kludges like holders if any type could have proper constructor and destructor, access types included. >> IMHO, Pure packages are too restricted to be useful (and not restricted >> enough to be useful when synchronization is involved); it makes sense for >> individual subprograms but not for an entire package. So I recommend only >> trying to make packages Preelaborated. (That's especially true in Ada 2012, >> where limited I/O is possible.) [Distribution might change this thinking; >> I'm only considering stand-alone programs that don't use Annex E.] > > That's probably truer than I'd like -- but I guess the question was > borne out of playing around w/ pure units and seeing how far I could > push the style-guide's instruction "Use pragma Pure where allowed." A lot of use cases conflated into single pragma Pure: 1. Value/object identity 2. Elaboration 3. Early evaluation (e.g. compile time, elaboration time) It must be reworked from the start, IMO. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de