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=ham 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.204.132.81 with SMTP id a17mr270651bkt.4.1336610834576; Wed, 09 May 2012 17:47:14 -0700 (PDT) MIME-Version: 1.0 Path: h15ni4719bkw.0!nntp.google.com!news2.google.com!goblin3!goblin1!goblin.stu.neva.ru!news.tornevall.net!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: What would you like in Ada202X? Date: Wed, 9 May 2012 19:47:09 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <3637793.35.1335340026327.JavaMail.geo-discussion-forums@ynfi5> <172r5u18q2247.ze0a856uvhqt.dlg@40tude.net> <1nmd7pjdxlzs1.cwtljox0244r.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1336610833 3823 69.95.181.76 (10 May 2012 00:47:13 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 10 May 2012 00:47:13 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2012-05-09T19:47:09-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:kl5nkc2s9tsx.61oqe3a9ogra.dlg@40tude.net... > On Tue, 08 May 2012 22:20:21 +0300, Niklas Holsti wrote: ... >> I'm sure there are complications to sort out. I haven't thought very >> long or deep about this. If people are interested in this idea, it would >> motivate some effort on it. > > Second to this! Instead of perpetual hand waving about compatibility and > imaginary evils of MI, we, Ada community, should consider how to sort the > mess out. There is no mess to sort out. MI is evil and the worst thing ever to happen to Ada was the inclusion of interfaces in Ada 2005. It is imcompatible with Ada's goals of fast running code, and simply shouldn't be allowed at all. (If I'm starting to sound like "anon" on this, I apologize... ;-) >> I would like to make the "deepening" derivation as similar as possible >> to the derivation of enumeration types in > > With the problems solved you will get enumeration extension for granted. > Your proposal rounds about how to generate conversion functions. You can > generate in-conversion, but cannot out-conversions. The case of plain > extension has the opposite problem: in-conversions are impossible. But the > mechanics of all this is same: interface inheritance, delegation of some > inherited operations to the parent's body composed with a conversion. > > 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. 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. Here I agree with Dmitry (but note that the mechanism he is talking about here has nothing to do with multiple inheritance; it works just fine with Ada 95 type derivation or something similar to that). It makes more sense to allow the programmer to provide the needed conversion functions than to come up with special features for doing that. I designed a straw-man "Root_String" around such conversion functions (you can find it in AI12-0021-1), and in fact you don't even need any additional Ada facilities to make such a type very usable. You could make it even more usable by defining a way to get user-defined slicing and literals (the conversion functions alone don't work for literals because of ambiguity problems, forcing qualification of all literals would be madness). This wasn't vetted by anyone, so take it with a grain of salt...but it illustrates the possibilities. Randy.