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.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA 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.223.40 with SMTP id qr8mr10245483pbc.0.1337265627260; Thu, 17 May 2012 07:40:27 -0700 (PDT) Path: pr3ni9355pbb.0!nntp.google.com!news1.google.com!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: What would you like in Ada202X? Date: Thu, 17 May 2012 17:40:24 +0300 Organization: Tidorum Ltd Message-ID: References: <3637793.35.1335340026327.JavaMail.geo-discussion-forums@ynfi5> <172r5u18q2247.ze0a856uvhqt.dlg@40tude.net> <1nmd7pjdxlzs1.cwtljox0244r.dlg@40tude.net> Mime-Version: 1.0 X-Trace: individual.net AWUeGjM3tadjd2Tg+w5UEwi9AGmtOzSlrbyTt5yeFLbq3KDg8VK1Ppn2Tz6r0FMSEB Cancel-Lock: sha1:f29k3V4kVNF63CG3aI7iicd5uUM= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2012-05-17T17:40:24+03:00 List-Id: 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? > 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. >>> 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 :-] > 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. > 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). > X1 : T1; > X2 : S1; > Y1 : T2; > Y2 : S2; > begin > D (X2, Y1); -- Illegal? This is D (S1, T2), legal by declaration 2. > D (X1, Y2); -- Legal but Constraint_Error (Ada 95 hack) This is D (T1, S2), legal by declaration 3. Sorry, which "Ada 95 hack" do you mean? > 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. 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. This is not possible for the "deepened" enumeration types. > 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. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .