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 10:19:02 +0200 Organization: cbb software GmbH Message-ID: <9b0anu6u678j.kfliatroezt0$.dlg@40tude.net> References: <7f1c01c5-3563-4b94-9831-152dbbf2ecdc@googlegroups.com> <8bhozh836pyt$.1qctlysud0s2q$.dlg@40tude.net> <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> 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:19402 Date: 2014-04-19T10:19:02+02:00 List-Id: 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. >>> >>> OK, but from the implementation point of view, that form of by-copy >>> passing could be used for all operations of a tagged class, whether >>> class-wide or primitive, with or without redispatching. So it is not >>> evident why you said earlier that redispatching prevents by-copy semantics. >> >> Re-dispatching presumes the same object. > > No it doesn't. Why should it? Redispatch merely selects an operation > based on the actual type (tag) of the parameter value. This is called dispatch. > 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? It is 1) the same polymorphic operation and 2) the same object. Take either away and it is not re-dispatch anymore: 1. Different operations: X.Foo; X.Bar; -- This is not re-dispatch! 2. Different objects: X.Foo; Y.Foo; -- This is not re-dispatch! >> For by-copy objects a conversion >> of T to T'Class would produce a new object on which dispatch would happen. >> It would make no sense to call this re-dispatch. > > I don't see why two > successive dispatching decisions on the same tag value should not be > called redispatching. It is irrelevant whether the tag value is copied > between the decisions. See above. >> But more importantly is that "re-dispatch" will always dispatch to the >> operations of the manifested type. I will consider this in details below. >> >> ... Consider this: >> >> type T is non-tagged null record; > > Are you talking about Ada here? We were talking about implementation dispatch and re-dispatch for by-copy types. Remember? If yes, that I am also pretty sure you know that this not Ada, so far. >> procedure Foo (X : T); >> procedure Bar (X : T); >> >> type TT is new T with record >> I : Integer; >> end record; >> overriding procedure Bar (X : T); >> >> procedure Foo (X : T) is >> begin >> T'Class (X).Bar; > > Ah, you are taking the class of a non-tagged type. So this is the > Dmitry-language, not Ada, nor a by-copy variant of Ada. There is no such thing as by-copy variant of Ada. >> end Foo; >> >> O : T'Class := T'(null record); >> >> O.Foo; >> >> The representation of O is (T'Tag, null record). When it dispatches on O to >> Foo, T'Tag is stripped away and null record is passed to T's Foo. Within >> Foo X has the representation null record, *always*. When X is converted in >> Foo to T'Class, the result is (T'Tag, null record), because the type of X >> is declared as T. When it dispatches on the result Bar, it is T's Bar that >> is called, always, because the tag is T'Tag. >> >> As you see, there is no re-dispatch possible with by-copy semantics. > > You are presenting a particular form of by-copy, in which the tag (and > no doubt all extension components) are removed when the value is copied > in a call to a non-class-wide operation. Obviously redispatch is not > possible then. But that is not the only possible way of passing > parameters by copy. I gave a use case. If you think that there could be another way to implement it, we could consider it. 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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de