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 X-Google-Thread: 103376,2ff5c149712ec0eb X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!newsfeed.freenet.de!news.teledata-fn.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Ada Interfaces and the Liskov Substitution Principle Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1k165n4jwxna3$.1mpx49xvcrc0z$.dlg@40tude.net> <1180254636.632499.3340@o5g2000hsb.googlegroups.com> <1p717twnydnre$.1j6izygvqo832.dlg@40tude.net> <1180425803.422075.100090@o5g2000hsb.googlegroups.com> <1180452858.118039.67740@w5g2000hsg.googlegroups.com> <1180510814.812025.251580@u30g2000hsc.googlegroups.com> <1180529642.741098.224230@q66g2000hsg.googlegroups.com> <1ljmbgesxien.syhurcvjdcd2$.dlg@40tude.net> <1180558336.041236.211560@p77g2000hsh.googlegroups.com> <1j91i6rk18kqd.4zjp36eyvps3.dlg@40tude.net> <1180619211.595952.116690@k79g2000hse.googlegroups.com> <1180704750.516171.126220@h2g2000hsg.googlegroups.com> <1r1lyrsyvr52v$.vx1t785sxb9u.dlg@40tude.net> <1180729864.936057.258970@p47g2000hsd.googlegroups.com> Date: Sat, 2 Jun 2007 10:19:44 +0200 Message-ID: NNTP-Posting-Date: 02 Jun 2007 10:19:41 CEST NNTP-Posting-Host: 19a81a8a.newsspool3.arcor-online.net X-Trace: DXC=CbB;Pe\5NON@k=MdN::NBIMcF=Q^Z^V3H4Fo<]lROoRAFl8W>\BH3YB18WbRhN6>1BDNcfSJ;bb[EIRnRBaCd On Fri, 01 Jun 2007 13:31:04 -0700, Maciej Sobczak wrote: > On 1 Cze, 16:53, "Dmitry A. Kazakov" > wrote: > >> or claiming that there is a semantic difference between X:=Y >> and Assign(X,Y). I don't want a language with magical, semantically >> non-decomposable assignments. > > You have them at the level of fundamental types. So what? > You can treat X:=Y and Assign(X,Y) to be equivalent for *your* T (and > if you have complete control over overloading of assignment then that > might be actually the case), but at some level of detail they have to > be implemented in terms of *non-decomposable* assignments of > fundamental types anyway. How a fundamental X:=Y differs from fundamental Assign(X,Y)? The question is not about implementation of, but about semantic differences. (It is the first time I meet somebody who tries to deny procedural decomposition. You have to chance.) > Now, the difference between T and T'Class is > that operations with T can be statically decomposed down to this non- > decomposable bricks. With T'Class it's just impossible to do this > mechanically and it's unrealistic to expect it from the programmer for > any non-trivial hierarchy. The operations of T'Class are perfectly decomposable. There are two of them (in Ada) 1. Class-wide operation has one body. 2. Primitive operation. The body is composed out for the bodies of the operations defined for the specific types. This precisely means: 2.a. The specific body is explicitly overridden 2.b. It is inherited, and thus, it is built as a composition of a type view conversion and the body of the parent type. >>> You can replace a Circle with a Triangle but you better not try to >>> assign them. >> >> This is not an explanation. Show a semantic difference between changing a >> name binding from one value to another by A) "replacement" and B) >> "assignment." > > No problem. Replacement is when you just stop refering to X and start > refering to Y (or its clone if the objects are mutable). Assignment is > when you decompose down to real, hard-core-metal-and-concrete ':=' on > fundamental types. Mixing abstraction levels is a logical fallacy. You have to choose one, which would define the semantics. Take any of above and show a difference: either between "start to refer" and "start to have", or else between the sequences of machine implementing "start to what." > The difference is that (in Ada terms) replacement > allows you to change the tag. Assignment cannot do this. Neither can. But to show this we'd need to formalize it. Briefly: types access T and T are different types. The semantic of assignment of access T is not one of T, and neither is of the assignment of T'Class! It is a typed language, after all... >> Ah, wouldn't replacement double dispatching? > > No, it wouldn't and that's the second difference. Replacement just > gets rid of the current value before the new value is refered to, > which means that from the dispatching point of view this operation is > simply linear on right-hand-side - it's a pure single dispatch. No, this does not work. Apart from being semantically wrong in general case, it is technically wrong. You have to dispatch to finalize LHS. You have to dispatch to re-construct it from RHS. See above, in Ada there is no choice beyond class-wide and primitive operation. The latter dispatches immediately, the former postpones the dispatch until its body. In both cases it ultimately dispatches on both arguments. So semantically there is no difference. Also see my earlier posts about ambiguity of the signatures T x T'Class and T'Class x T in presence of derived types. > Assignment has to be '2D' with both axes, or O(n2) in terms of > implementation complexity. It has to be double-dispatching to make any > sense and this is unrealistic implementation-wise. It is semantically this way. There is nothing to do about it, but to scrap either assignment or class. (We are going in circles) > That's why T'Class, even though very interesting from the language > construction point of view, cannot entirely include all functionality > of access variable to T'Class (or pointer to base class in C++ > jargon). This is irrelevant as they are different types. In fact an access type could be treated as a member of the class, but then its assignment would have a deep copy semantics and you are back where you have started from. (C++ OO model is really poisoning. Don't mix types, just don't.) >> Then let "assignment" := >> "replacement," > > Do you mean: > - let's replace assignment by replacement, or > - let's assign replacement to assignment? > > ;-) Take what you wish, but referential semantic is fundamentally insufficient, in the sense that you cannot have a language without values, but only references. This is the conceptual fault of Java et al. Once you had at least one value at the end of the referential chains, you'd have to assign (:-)) it and give a type to it. (It is about typed languages, right?) Then because your types algebra has classes one could create a class of. In the end you will face the same question again: what is the assignment on the class. All this referential stuff is just shifting subjects. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de