Re: Record operations (Algebraic Data Types and printing)

[Shark8 <onewingedshark@gmail.com>]

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.

T'Image is related *only* in that it's supposed to be the inverse of T'Value.

> 
> > 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.)

> 
> > 'Value would need something similar at a minimum, and the question of
> > privacy breakage also would have to be addressed (a package would not want
> > some outside force constructing values for its types; they might not meet
> > the [implied] invariants and other assumptions
> 
> [...]
> 
> 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.