From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Your wish list for Ada 202X Date: Sat, 19 Apr 2014 12:18:33 +0200 Organization: cbb software GmbH Message-ID: <132d3171q5dwr$.1i185khwx8gcz.dlg@40tude.net> References: <7f1c01c5-3563-4b94-9831-152dbbf2ecdc@googlegroups.com> <1cdsyxjzsfgzm.1synpaujysv21$.dlg@40tude.net> <1aa804jg9qq4o$.wdiq33yo621l.dlg@40tude.net> <1w6eh0aiksmdh$.1h16p7y0b8c6h.dlg@40tude.net> <17twpp4p8u7o$.1idvzaaio4f3t$.dlg@40tude.net> <1wjmcbk375lzk.6o7dpqcp3va3.dlg@40tude.net> <1kwpgk4mrnzey.18388dob823vp$.dlg@40tude.net> <129pvrzqrv83p$.orkstybnskgo.dlg@40tude.net> <9b0anu6u678j.kfliatroezt0$.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: AuYlnUSfTZrfhAkRjyySpQ.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:19410 Date: 2014-04-19T12:18:33+02:00 List-Id: On Sat, 19 Apr 2014 12:05:09 +0300, Niklas Holsti wrote: > On 14-04-19 11:19 , Dmitry A. Kazakov wrote: >> On Sat, 19 Apr 2014 10:35:36 +0300, Niklas Holsti wrote: >> >>> On 14-04-19 00:18 , Dmitry A. Kazakov wrote: >>>> On Fri, 18 Apr 2014 22:10:50 +0300, Niklas Holsti wrote: >>>> >>>>> (Apologies for a delayed reply.) >>>>> >>>>> On 14-04-14 00:07 , Dmitry A. Kazakov wrote: >>>>>> On Sun, 13 Apr 2014 22:43:47 +0300, Niklas Holsti wrote: >>>>>> >>>>>>> On 14-04-12 11:20 , Dmitry A. Kazakov wrote: >>>>>> >>>>>>>> I don't deny >>>>>>>> existence of the problem. I am against the solution, which is inherently >>>>>>>> unsafe and constraining (precludes by-copy semantics). >>>>>>> >>>>>>> But class-wide operations which contain dispatching calls also preclude >>>>>>> by-copy semantics, don't they? >>>>>> >>>>>> Not at all. There is no problem for a class-wide operation to act on >>>>>> by-copy types. >>>>>> >>>>>> A by-copy class-wide object is a tuple (tag, type-specific value). Upon >>>>>> dispatch the value is passed copy-in/copy-out to the type specific >>>>>> operation. > > I think I misunderstood you here. I now think you meant that only the > type-specific value (the second component of the tuple) is passed > copy-in/copy-out (but the tag is not passed). I misunderstood and > thought that you meant passing the entire tuple value (tag, > type-specific value) by copy-in/out. Yes >>> Whether the >>> operation acts on the same object or on a copy is a separate question. >> >> "Re-" presumes that dispatch happens again. What is in common to these two >> instances of dispatch what makes it re-dispatch? > > The fact that the calling operation has been reached by a dispatch on > the parameter's tag, and now a new dispatching call is made (dynamically > within the first dispatching call) based on this same tag. But some other object might also have this tag. E.g. when generic dispatching constructor is used. In my view, the tag is same because the object is. Since tagged types magically make the tag accessible and preserved, you could use it to construct a class-wide object and then dispatch again. As a side note, observe that preserving the tag is not a requirement, semantically. For example, upon object's initialization (finalization), the object's tag ascends (descends) the inheritance path, e.g. in C++. >> In particular, the case, which is especially interesting and important for >> by-copy types, when the derived type has a representation completely >> different from the base. For instance: >> >> type Wide_Wide_Character is ...; -- Full Unicode >> function Is_Digit (X : Wide_Wide_Character) return Boolean; >> function Is_Letter (X : Wide_Wide_Character) return Boolean; >> function Is_Alphanumeric (X : Wide_Wide_Character) return Boolean; >> >> type Character is new Wide_Wide_Character without parent's mess ...; >> overriding function Is_Digit (X : Character) return Boolean; >> overriding function Is_Letter (X : Character) return Boolean; >> >> Let you wanted re-dispatch in Is_Alphanumeric to Is_Digit and Is_Letter. > > Could you complete your thought here? I don't see a claim or a question yet. The claim is that there seems no other way to implement Wide_Wide_Character'Class than as I described earlier. The representation of a class-wide object containing, say, ROMAN_DENARIUS_SIGN will be (Wide_Wide_Character'Tag, ROMAN_DENARIUS_SIGN) The representation of a class-wide object containing character 'A' will be (Character'Tag, 'A') Note, this is different from: (Wide_Wide_Character'Tag, LATIN_CAPITAL_LETTER_A) Though both would refer to the same Unicode code point. When you dispatch on (Character'Tag, 'A') to Is_Alphanumeric, the parameter of Is_Alphanumeric will be 'A'. You could not re-dispatch from there to anything but to character's operations. Note, that if Is_Alphanumeric were inherited, rather than overridden, as in the example above, the original body would be composed with a conversion to the parent type. The effect would be: Is_Alphanumeric (Wide_Wide_Character ('A')); Wide_Wide_Character's is Is_Alphanumeric (x) Character's is Is_Alphanumeric is Is_Alphanumeric (Wide_Wide_Character (x)); ^^^ inherited body ^^^ added per inheritance This is exactly the semantics of Ada's tagged types as well. The conversion in the case of a tagged type is a view conversion and thus a null-operation. [Only when there is no MI, actually. In presence of full MI view conversion could require adjusting the reference to the object] The bottom line is, you cannot preserve the tag upon dispatching with by-copy object. Therefore, no re-dispatch will be possible for them. And the mantra sung here that any reasonable change would break Ada is a distraction used to shut up the discussion. Ada 95 design of classes was sound and it is quite possible to extend it to all types. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de