Re: Record operations (Algebraic Data Types and printing)

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

On 2018-10-11 23:35, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:ppk92s$4ht$1@gioia.aioe.org...
>> On 2018-10-10 00:20, Randy Brukardt wrote:
>>> "Lucretia" <laguest9000@googlemail.com> wrote in message
>>> news:fb2af9cb-5317-4f1c-867c-8876212d303b@googlegroups.com...
>>> 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?
> 
> Sorry about the sloppy language, I was referring to the default Image string
> representation for a type.
> 
> The proposal for 'Image defines such a representation for all types (for a
> task, it is the task id and discriminants, for instance). It's not clear how
> to define 'Value usefully for such a representation (most likely it would
> not be).
> 
> In any case, it is a non-trivial problem, substantially harder than the
> matching problem for 'Image.

Another difficult problem is to define rules how 'Image and 'Value of a 
composite type should use or not use 'Image and 'Value of the components 
and ancestors. Say Image of a component gets overridden. Does it have 
effect and when? Does it change the behavior later on or only newly 
compiled modules, only those where overriding is visible, directly? etc. 
I.e. is any call to Image is always "dispatching"?

This is why do not like all these language hacks. Image/Value must be an 
interface inherited, standard rules apply.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de