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.191.225 with SMTP id hb1mr5138426pbc.5.1336376998583; Mon, 07 May 2012 00:49:58 -0700 (PDT) Path: pr3ni13611pbb.0!nntp.google.com!news1.google.com!goblin3!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: Mon, 7 May 2012 09:49:32 +0200 Organization: cbb software GmbH Message-ID: <1nmd7pjdxlzs1.cwtljox0244r.dlg@40tude.net> References: <3637793.35.1335340026327.JavaMail.geo-discussion-forums@ynfi5> <172r5u18q2247.ze0a856uvhqt.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.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-07T09:49:32+02:00 List-Id: On Mon, 07 May 2012 00:26:52 +0300, Niklas Holsti wrote: > On 12-05-06 22:28 , Dmitry A. Kazakov wrote: >> >> Yes, for tagged types operations which are unsafe to inherit are inherited >> abstract, e.g. functions returning covariant value. > > The same could be done also for extension by deepening, but it is not > needed, as long as we don't introduce tags and class-wide programming > for these types. Inheriting these operations as abstract could even be > inconvenient, since it would force the program to implement (override) > the operations even when they are not needed. What are you going to do with user-defined operations? In the model (1) where the derived type is a subtype (in Ada sense) they get automatically inherited in any context where visible. [This in effect makes you exposed to "class-wide" programming with subtypes even if you don't want to. All subtypes of a type form a class with ad-hoc operations gathered from all members, when visible.] In the tagged model (2) the derived type is independent and any specific operations of the parent are dropped. >> This looks like plain interface inheritance. You inherit the interface (the >> literals of the type) dropping the implementation (encoding). > > Not quite, because the derived type does not inherit the literals that > are refined. Detailed_Message_Kind does not have the literals Request > and Reply, because they have been refined into the literals Read and > Write, and into the literals Data, Ack, and Refused, respectively. OK, +operation disallowing. This would not work in the model #1. (I guess that difficulties with enumeration extension proposals stem from attempts to force it under the model #1) >> Parent's >> operations are inherited per composition with a type conversion. > > Yep. > >> I always wished to have this mechanism in Ada. Note that instead of >> inventing some complicated syntax which purpose is basically to generate >> conversion functions (four conversions are needed in most general case), >> you should just allow the programmer to define them by himself. > > There is a trade-off. Using syntax constrains the kinds of conversions > the programmer can use, which may help compilation and code generation. > Programmer-defined unrestricted conversion functions could become too > complex for efficient compilation. Possibly, though a more general construct would reduce the number of cases the compiler designer should go though. I think that combinatorial explosion of variants could be a bigger problem for the optimizer. >> My opinion is that the language should provide very few fundamental >> primitives rather than a forest of special cases. > > I agree, in theory. In practice, it is difficult, even if you could > define a language from scratch. Yes. More general constructs have more power, which needs to be carefully constrained in order to keep the language safe. C and PL/1 give us examples of the damage type conversions may inflict. > It is even more difficult for Ada > because of the compatibility requirements. On the contrary, it is rather specific extensions which likely are to become incompatible. Generalizations are less problematic, you simply define old constructs in new terms. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de