Re: Parameterised 'Image Attributes

["Randy Brukardt" <randy@rrsoftware.com>]

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

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

>> '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! ;-)

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

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. (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.) That 
would make a library simple to use, and few people would think that 
something builr-in is needed.

                         Randy.