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!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Record operations (Algebraic Data Types and printing) Date: Thu, 11 Oct 2018 10:36:40 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <0f5608ef-0038-491c-b15f-f67bcc76fae8@googlegroups.com> <00285ebf-6ede-44da-848f-456930dc7475@googlegroups.com> <3620199a-f025-4099-83ad-a1e5042dc6c0@googlegroups.com> <8903c94f-efc7-4a2c-9513-ee17890b49d2@googlegroups.com> <644dc84a-1e0c-4a1b-9672-38709acf1faa@googlegroups.com> NNTP-Posting-Host: MyFhHs417jM9AgzRpXn7yg.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 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.3 Xref: reader02.eternal-september.org comp.lang.ada:54537 Date: 2018-10-11T10:36:40+02:00 List-Id: On 2018-10-10 20:38, Shark8 wrote: > On Wednesday, October 10, 2018 at 1:17:51 AM UTC-6, Dmitry A. Kazakov wrote: >> On 2018-10-10 00:20, Randy Brukardt wrote: >>> "Lucretia" wrote in message >>> news:fb2af9cb-5317-4f1c-867c-8876212d303b... >> >>>> Like what 'Read/'Write/'Input/'Output do, they call a defined subprogram in >>>> the package. Surely, it's not that hard. >>> >>> What package? We're talking about (in part) the default representation for a >>> type. >> >> What have T'Image and T'Value to do with the type representation? > > Well, T'Value would need two things: (1) to read from the stream, and (2) produce the proper value of the type. This might require knowing the representation, such as a set of flags modeled by an "Array(1..8) of Boolean" [with Size => 8] being packed into a single byte. Whatever way the implementation chooses. Full visibility of the type or some of its parts might be required or not required. The default implementation could respect visibility or ignore it. >>> Stream attributes use a complex concept called "availability" to deal >>> with limited types, and they don't worry about privacy breakage at all. >> >> Limited types should have no stream attributes at all. Same applied to >> 'Image/'Value. Returning limited object was a language design bug. This >> cannot be fixed but it can be contained. > > I'm not sure about this. There's a good argument for it if you're (eg) modeling/interfacing into hardware... but there's argument against it if your purpose is merely controlling data. -- An example I could think of is some sort of keyed-index ownership-scheme where there's only one value of that particular type at a time, and some need for persistence across program runs. (Wherein the values are saved to disk in program-shutdown, and restored in program-start-up.) The question is whether this behavior is safe to provide by default. The answer is no, most of the time it is unsafe and meaningless. The rest can be easily covered without using streaming attributes. BTW, in practice they would not work anyway. I implemented what you described on several occasions. Each time I ended up with reading from the stream not the limited object but a handle to it instead. The handle's 'Read attribute read the object parts from the stream, allocated the new object, constructed it in place and then returned a handle to it. Limited return+aggregates simply do not work when you have derived types and private parts. >> Safe default is to generate publicly visible 'Image and 'Value >> propagating Use_Error for all types with private components. The package >> provider could override them in the public part with bodies renaming the >> private default implementations of which have full visibility. > > Or, we could just let the attributes [functionally] act as callbacks, albeit statically rather than dynamically assigned. Thus you could invoke T'Image for anything w/ the attribute and have a good compile/run (even if the default provided by the compiler is USE_ERROR)... then add in an implementation, use "For T'Image Use ..." or " with Image => ..." (perhaps in the private section) and compile/run it w/o having altered the public/visible interfacing. Yes, this is how stream attributes were forced into the language. But the question was about what to do with default implementations without full visibility. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de