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=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: border1.nntp.dca3.giganews.com!backlog3.nntp.dca3.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!goblin3!goblin2!goblin.stu.neva.ru!news.internetdienste.de!news.tu-darmstadt.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Your wish list for Ada 202X Date: Sat, 19 Apr 2014 10:35:36 +0300 Organization: Tidorum Ltd Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: individual.net 1gIe42ZWgpEVZsQMuJfcLwKS0LMmpkmgZkSDNQ9Ls6sf+BkMPJ Cancel-Lock: sha1:pgjbQBdqvZLPkEqiokPM9pYvKwE= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 In-Reply-To: <129pvrzqrv83p$.orkstybnskgo.dlg@40tude.net> X-Original-Bytes: 6554 Xref: number.nntp.dca.giganews.com comp.lang.ada:185835 Date: 2014-04-19T10:35:36+03:00 List-Id: 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. Whether the operation acts on the same object or on a copy is a separate question. > 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. In earlier discussion threads, you have criticized redispatching as logically redundant because it inspects the object's tag twice, making two dispatching decisions where one should be enough. Here, even if T'Class makes a new object, the new object has the same tag value, and a dispatching call on it makes a new decision using the same tag value as was used to dispatch to the calling operation. 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. > 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? Or about the ideal Dmitry-language? > 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. > 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. >>>> 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. Ok, a misunderstanding between us, we do agree that there is no dispatching when a class-wide operation is called. But a side issue. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .