Re: Parameterised 'Image Attributes

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

On 2023-08-22 01:34, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:ubsn75$1a024$2@dont-email.me...
>> On 2023-08-20 09:25, Randy Brukardt wrote:
>>
>>> Additionally, one ends up with a magic mechanism that only the compiler
>>> can
>>> use. That *never* is a good idea.
>>
>> A better idea would be to improve the language to remove need in magic,
>> but that is *never* a good idea either! (:-))
> 
> No, I generally agree with this. We probably disagree on what would
> consistute an improvement, however. ;-)

To the same effect...

>>> Attributes do not allow named parameters outside a few special cases, and
>>> *never* allow reordering of parameters. Does that need to change, too?
>>
>> Elementary! Attribute is just an alternative syntactic form of a
>> subroutine call. There is no reason why attribute should be limited to
>> look like FORTRAN IV! (:-))
> 
> That turns out to be a bad idea. The reason people love attributes so is
> that they don't have to worry about visibility -- they're always visible.
> That is not and cannot be true for subprograms.
> 
> For example, the reason that we don't allow user-defined attributes is that
> they would compromise portability. Since they're always visible, they could
> hide/make illegal attributes that are used in units (like generic units)
> that don't know anything about the additions.

In other words attribute is a primitive subprogram, yes.

> Moreover, not all attributes
> can be described as subprograms given Ada's current rules (reduction
> attributes have a type parameter; some of the annex 13 attributes have "any
> type" parameters, etc.)

It is a primitive subprogram of some built-in class. The magic is not in 
the attribute, it is the class description. For magical classes 
overriding a primitive operation could look like

    for <member-type>'<primitive-operation-name> use <subroutine-name>;

> It certainly would be a very bad thing for Janus/Ada, which would have to
> have its resolution and subprogram definition mechanisms redesigned. (All
> subprograms are materialized in the Janus/Ada symboltable, in particular for
> visibility management reasons, and that would not be possible for
> attributes. Resolution only works on materialized subprogram definitions.)

Only if you wanted to remove all magic, which is never be possible. But 
you can do some.

>>> 'Image is convinient for integer and enumeration output, and one can
>>> format
>>> them in the rare case where that is necessary. But it is useless for
>>> float
>>> output -- manual reformatting the output of 'Image would round the
>>> results
>>> incorrectly.
>>
>> Which is why Float 'Image must have parameters!
> 
> Which is why one shouldn't use Float'Image! ;-)

Any application programmer will tell you that all types must have 
'Image! (:-))

>>> Ada has few built-in facilities because it's primary purpose is to
>>> support
>>> the development of proper ADTs. Ease of writing is not a goal at all, and
>>> in
>>> most cases, the extra text is valuable to compilers and tools (even if it
>>> is
>>> not so valuable to human readers).
>>
>> How is this related to attribute 'Image lacking necessary parameters? Why
>> generic function having such parameters is OK, while 'Image with same
>> parameters is not?
> 
> It's perfectly OK to overload functions however one wants, because you can
> keep anything that is problem from being considered by avoiding "use" (and
> "with").
> 
> 'Image is not appropriate for an attribute in the first place; attributes
> are supposed to be simple compile-time defined properties of a type. String
> conversion is not that.

But stream serialization is?

The problem is that whatever intention Ada designers had for attributes 
they also gave them property of being a primitive operation where no 
user-defined class allowed. This power steamrolls any "good" intentions.

Nobody loves the syntax T'Image (X) or X'Image! Give programmers X.Image 
and [<path-of-package-names-nobody-remembers>].Image (X) and they will 
forget about the attribute.

> My preference for making Ada easier to use for this sort of thing is allow
> class-wide elementary types. Then one could have non-generic subnprograms
> that operation on all integer and float types.

Yes.

> (Fixed and enumerations would
> still require generics, although I suspect most people would simply convert
> fixed to float for output rather than worrying about an instantiation.)

It would be interesting to play with the ways of constructing 
enumeration and fixed point classes. Both have static parameters, e.g. 
list of names in the case of enumeration. There might be a way achieve 
static polyphormism without going full generic but also without turning 
the language into a C++ templates mess!

> That
> would make a library simple to use, and few people would think that
> something builr-in is needed.

Absolutely. Ideally, everything must go into libraries.

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