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,81bb2ce65a3240c3 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.220.230 with SMTP id pz6mr3203966pbc.3.1337274785242; Thu, 17 May 2012 10:13:05 -0700 (PDT) Path: pr3ni9743pbb.0!nntp.google.com!news1.google.com!goblin1!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: What would you like in Ada202X? Date: Thu, 17 May 2012 19:12:57 +0200 Organization: cbb software GmbH Message-ID: <1jtp5pxiewgda$.vsrzwbgrddt5.dlg@40tude.net> References: <3637793.35.1335340026327.JavaMail.geo-discussion-forums@ynfi5> <172r5u18q2247.ze0a856uvhqt.dlg@40tude.net> <1nmd7pjdxlzs1.cwtljox0244r.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: 4RFYTQ6jM/dAKFJoI0fUkg.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: 2012-05-17T19:12:57+02:00 List-Id: On Thu, 17 May 2012 17:40:24 +0300, Niklas Holsti wrote: > On 12-05-09 11:02 , Dmitry A. Kazakov wrote: >> On Tue, 08 May 2012 22:20:21 +0300, Niklas Holsti wrote: >>> >>> Perhaps the derived "deepened" type could inherit operations with "out" >>> and "in out" parameters of the parent type if these parameters were kept >>> as parent type, and not mapped to the derived type >> >> No, they must be inherited exactly same way > > "Must" by which authority? (Logic, common sense?) IF you inherit them, THEN the mechanism must be same. >> parameter of derived type when inherited, that is covariance. When an in >> operation is inherited it too has the parameter of the derived type, which >> is then converted and passed to the inherited body. For out-operations you >> call the inherited body and then convert the result. For in-outs, you >> convert-in, call, convert-out. >> >> You might mean that composition with conversion could be inappropriate >> here. > > For result values ("out", "in out", "return") conversion is > inappropriate because there is no natural conversion in that direction. If these operations are inherited, then semantically there is such a conversion. The compiler is not allowed to reason about program semantics. >>>> This would exclude all functions returning values of the type. In >>>> particular T'Val, T'Succ, T'Pred. Are you going to define some of them new? >>> >>> Of course the derived "deepened" type must have these operations, since >>> it is an enumeration type, >> >> (See how quickly multiple inheritance slips in? (:-)) > > Only in your wide view of what "multiple inheritance" means :-] And what does it mean in the narrow view of MI-haters? (:-)) >> This is why it makes no sense to implement it for specifically enumeration >> types. The disadvantages it may have (rather imaginary ones, IMO) will all >> be yours. So why not to face it, and just do it for all types. Sorry for >> advocating this for years, but there is no other way. > > I wish you would write up your proposal in a self-contained form. Yes, > you have been advocating this, but in scattered postings, and so > sketchily that it has not IMO been possible to understand and discuss it. In case, you didn't notice that, there is no interest in such proposals. I hope that our discussion will convince at least you, that it is worth to consider ways Ada's type system could be significantly generalized and simplified while keeping it fully backward compatible. >> You will have to solve MD problematic as well. E.g. >> >> type T1 is (...); >> type T2 is (...); >> procedure D (X : T1; Y : T2); > > - Declaration 1: D (T1, T2). >> >> type S1 is new T1 with ...; > > Inheritance from declaration 1 gives: > > - Declaration 2: D (S1, T2). > >> type S2 is new T2 with ...; > > Inheritance from declaration 1 gives: > > - Declaration 3: D (T1, S2). > > Inheritance from declaration 2 gives: > > - Declaration 4: D (S1, S2). That is full MD! Putting our "diamond mine" at work: put S1 in one package, S2 in another. Neither knows other. Where D(S1,S2) gets inherited? Unlike to MI, diamond issues for MD are real. > Sorry, which "Ada 95 hack" do you mean? Ada 95 inherits some MD operations as "raise Constraint_Error" without giving an ability to override (only for multi-methods). >> Semantically, there always will be some issue with conversions, because any >> non-trivial modification of a type, must break something. If it did not, >> you would use the old type instead. > > Yes. Tagged types get around that by using view conversions. You mean here rather type extensions, not in the sense of enumeration extension but as a Cartesian product of the values of the parent type and the extension part. They could be by reference and by value. E.g. you could extend Float to Complex by "multiplying" Float x Float. > But that is > only possible because a value of a derived tagged type in effect > contains a value of the parent type, which is independent of the other > components that were added in the derivation. The parent-type value can > therefore be changed (by "out" or "in out") without considering the > added components. Strongly disagree. The internal representation is irrelevant. An ability to generate some type conversion as a view conversion does not mean that the result of such conversion is semantically correct (substitutable). The semantics is defined by the programmer in terms of type operations. It is up to him to decide whether the operation can be inherited per composition with [view] conversion or not. > This is not possible for the "deepened" enumeration types. Yes, but irrelevant. I would even claim that in the language like Ada the compiler should inherit everything abstract. The programmer should always override explicitly saying if the body is composed per view conversion (or any other built-in conversion) or overridden (or extended by adding prologues/epilogues etc). The only reason not to do this is lack of good syntax sugar to avoid tedious repetitions. >> It is not the language business, it is >> up to the programmer to resolve. The language should simply refuse to >> automate suspicious cases forcing the programmer to intervene. > > In that case, it seems the language would have to be extended further, > to let programmers write conversion functions that can convert not only > values, but also "views" of some kind. Yes. It would be useful, e.g. dereferencing fat pointers. Or you could make something task-safe by seizing mutex while passing converted argument and releasing it when returning back. Then, of course, for all sorts of in-place operations of containers: you could derive an ad-hoc container element type and hang conversions passing the container in the closure which would modify the element in place. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de