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: Fri, 18 Apr 2014 23:18:12 +0200 Organization: cbb software GmbH Message-ID: <129pvrzqrv83p$.orkstybnskgo.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> 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:19391 Date: 2014-04-18T23:18:12+02:00 List-Id: 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. 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. But more importantly is that "re-dispatch" will always dispatch to the operations of the manifested type. I will consider this in details below. > If I may guess, your reasoning is perhaps that if we have a tagged type > T, and a derived type TT with added components, and a primitive > operation Foo on T which is inherited by TT and uses by-copy semantics, > then calling Foo on a TT object X should really copy only the T part of > X, and therefore Foo could not execute a redispatching call to some > operation Bar on T which is overridden for TT, because the conversion > T'Class(X) in the redispatching call would have no way to (re)generate > the TT components of X, because they were not copied. > > I think that argument is wrong from the formal point of view, because > when Foo is inherited from T to TT, the inherited operation formally > acts on TT, therefore the by-copy passing would copy all of X, including > the TT components. Consider this: type T is non-tagged null record; 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; 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. Re-dispatch requires: 1. by-reference semantics (no new objects) 2. extension (parent representations stored within derived objects) 3. embedded tags (class-wide and type-specific representations to be same) > Another case that comes to mind is an explicit call to the original (not > inherited) form of Foo, using a call with a conversion of the form > Foo(T(X)) where X is of type TT. Here, there is more reason to feel that > by-copy passing should copy only the T part of X (or, rather, the > conversion should return only the T part of X), and then redispatching > from Foo would indeed be impossible. But if T(X) is seen simply as a > view conversion, not a value conversion, then X could still be passed > by-copy using your (tag, type-specific value) form. It is the tag in the pair (Tag, Value) which determine the type of Value. You cannot use T'Tag with TT value, that is inconsistent. >>> A class-wide operation, in my view, is just like a primitive operation >>> except that (1) (re-)dispatching is implicit and automatic for all calls >>> to primitive operations of the parameter object (because the parameter >>> is a class-wide type) and (2) the operation cannot be overridden. >> >> There is no re-dispatching in a class-wide operation. It is defined on >> class-wide objects, so it simply neither dispatch nor re-dispatch. > > Huh? If a class-wide operation calls a primitive operation, using a > controlling parameter of the class-wide type, that is certainly a > dispatching call. Yes, but this is a call to some different operation. I thought you were talking about the class-wide operation itself. This operation does not [re-]dispatch. What happens in its body is a different issue. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de