Re: Record operations (Algebraic Data Types and printing)

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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