From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,T_SCC_BODY_TEXT_LINE, XPRIO autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Parameterised 'Image Attributes Date: Mon, 21 Aug 2023 18:34:55 -0500 Organization: A noiseless patient Spider Message-ID: References: Injection-Date: Mon, 21 Aug 2023 23:34:38 -0000 (UTC) Injection-Info: dont-email.me; posting-host="a646227c24097efbc8783f6ec1cd88e1"; logging-data="2210997"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+vhBDTJEGhqDA3YYROG03l7HWwtXuK4LI=" Cancel-Lock: sha1:sXEMcPDK9kbJsO8fruT82jdZuu4= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 X-Priority: 3 X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MSMail-Priority: Normal Xref: news.eternal-september.org comp.lang.ada:65549 List-Id: "Dmitry A. Kazakov" 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.