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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.99.133.194 with SMTP id u185mr1918121pgd.150.1492627806455; Wed, 19 Apr 2017 11:50:06 -0700 (PDT) X-Received: by 10.157.23.39 with SMTP id i39mr97380ota.8.1492627806387; Wed, 19 Apr 2017 11:50:06 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!t52no1971438qtb.0!news-out.google.com!y33ni362qty.1!nntp.google.com!c45no3799697qtb.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 19 Apr 2017 11:50:06 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=50.130.162.123; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 50.130.162.123 References: <178b6fbc-229b-49fc-8ffb-a5797bfc335f@googlegroups.com> <61e151c1-9fe6-4d32-8f13-d425bc41a616@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Is there a reason System.Storage_Pools isn't Pure? From: Shark8 Injection-Date: Wed, 19 Apr 2017 18:50:06 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:46597 Date: 2017-04-19T11:50:06-07:00 List-Id: On Wednesday, April 19, 2017 at 1:37:33 AM UTC-6, Dmitry A. Kazakov wrote: > 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 wa= s not > >> Pure. So I can't find any discussion of the merits. > >> > >> However, Pure packages are automatically Remote_Types packages (that i= s, > >> 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 a= ny > >> 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? >=20 > No, so long you don't know what is in the memory. Even considering the=20 > case of a shared [distributed] memory pool it cannot be pure. But of course you know what's in that memory: you put it there. [Well, the = compiler; and since accesses are typed of course we know what they are.] --= And a pool[-type] obviously can be pure, as it is only a definition, an in= terface, if you will. > E.g.=20 > initialization of an object in the shared memory must be done only once,= =20 > which does not preclude binding of each shared copy/view, like mapping=20 > pointers since copies may be located in different virtual address spaces. Huh? While 'pointer' and 'access' are forms of indirection, and conceptually the= same an access is safer as there is no untyped access. Further, if we use = the de facto standard that pointers are an integer (thanks C [/sarc]) then = we can recognize that an access needn't be so restricted. Indeed there are = cases where it *MUST* be more than an integer, like the case of an access t= o the value of an unconstrained array-type,as we *MUST* have the bounds. > > What about a usable-for-anything holder? >=20 > Huh, what about fixing initialization/fixed in the first place. We would= =20 > not need kludges like holders if any type could have proper constructor= =20 > and destructor, access types included. Perhaps, though maybe you should explain what a proper constructor/destruct= or is -- as I'm pretty sure that C++ style *isn't* what you have in mind. > >> IMHO, Pure packages are too restricted to be useful (and not restricte= d > >> enough to be useful when synchronization is involved); it makes sense = for > >> individual subprograms but not for an entire package. So I recommend o= nly > >> trying to make packages Preelaborated. (That's especially true in Ada = 2012, > >> where limited I/O is possible.) [Distribution might change this thinki= ng; > >> 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." >=20 > A lot of use cases conflated into single pragma Pure: >=20 > 1. Value/object identity > 2. Elaboration > 3. Early evaluation (e.g. compile time, elaboration time) 1. Value/object identity? I'm not sure where you're getting that from., cou= ld you elaborate/explain? 3. This is true; it would be nice to have a clear compile-time and elaborat= ion-time distinction. > It must be reworked from the start, IMO. Perhaps, though it does quite well in enforcing a lack of state upon the co= mpilation-unit; taken in that manner Pure does a good job as an indicator.