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.68.241.98 with SMTP id wh2mr3798524pbc.7.1337127553612; Tue, 15 May 2012 17:19:13 -0700 (PDT) MIME-Version: 1.0 Path: pr3ni3265pbb.0!nntp.google.com!news2.google.com!volia.net!news2.volia.net!feed-A.news.volia.net!news.ecp.fr!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: Tue, 15 May 2012 19:19:05 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <3637793.35.1335340026327.JavaMail.geo-discussion-forums@ynfi5> <20780405.1069.1336372385458.JavaMail.geo-discussion-forums@pbkc8> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1337127551 22717 69.95.181.76 (16 May 2012 00:19:11 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 16 May 2012 00:19:11 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2012-05-15T19:19:05-05:00 List-Id: "Niklas Holsti" wrote in message news:a1g0h2Fm2bU1@mid.individual.net... (I did read your whole message, but since I have to leave here ASAP, I'm just going to answer a quick summary.) ... > The widening derivation only adds. The deepening derivation changes, by > refining. I have never wanted to "refine" an enumeration. Perhaps its not even something I would think of (because it's not possible, so why even consider it), so I can't be certain that's because its rare, but off-hand, I can't think of any possible use of such a construct. Well, one, where you have a specific literal in your original type for "future expansion", and you then hang new literals on it. That is, using "deepening" to emulate "widening". So that's the main problem I have with your concept: it doesn't solve any real problems that I have. OTOH, the need to add a new (operation, border style, font choice, etc.) happens all of the time. I'm definitely not certain that there is anything that can be gained from having a language feature to do this. I understand your desire to keep apples and oranges separate, but typically these don't share operations either (most of the operations on these fruits are completely different - think removing seeds). That's why the value of untagged derived types is low (and that carries over to tagged types for many kinds of operations - few things map as well to OOP as GUIs). I could easily see a version of Dmitry's user-defined conversions to allow two otherwise separate types to share operations (but not representations), but a more specific feature just doesn't have enough bang-for-the-buck (the "buck" here being the effort to define and implement this in language terms). Randy.