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: a07f3367d7,81bb2ce65a3240c3 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.204.149.210 with SMTP id u18mr1260717bkv.1.1337315796263; Thu, 17 May 2012 21:36:36 -0700 (PDT) MIME-Version: 1.0 Path: e27ni7042bkw.0!nntp.google.com!news1.google.com!news3.google.com!feeder3.cambriumusenet.nl!feeder1.cambriumusenet.nl!feed.tweaknews.nl!194.134.4.91.MISMATCH!news2.euro.net!newsfeed.x-privat.org!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: Thu, 17 May 2012 23:35:27 -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 1337315730 30824 69.95.181.76 (18 May 2012 04:35:30 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 18 May 2012 04:35:30 +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-17T23:35:27-05:00 List-Id: "Niklas Holsti" wrote in message news:a1laqhFlkpU1@mid.individual.net... > On 12-05-16 03:19 , Randy Brukardt wrote: >> "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. > > I do it often, but in current Ada I have to do it "in reverse", by > defining the most detailed enumeration first, and then coarsening it into > larger-grained concepts by defining subtypes. For example, I write: > > type Detailed_Message_Kind is ( > Sign_On, Read, Write, Data, Ack, Refused, Sign_Off); > > and then coarsen it to subtypes: > > subtype Request is Detailed_Message_Kind range Read .. Write; > subtype Reply is Detailed_Message_Kind range Data .. Refused; > > This works, but it is a bit error-prone when I need to add some literals > and make sure that they go in the right subtype, and of course the > collection of "coarsening" subtypes does not itself form an enumeration, > so I cannot, for example, loop over all the "coarser" concepts. Ada 2012 helps here a bit because it doesn't require the subtypes to have contiguous literals. (That's a major pain in previous Ada.) A static subtype predicate can be used to specify a set of literals, and you can still use the subtype name in case statements and loops. But of course you can't loop over a bunch of subtypes, only one at a time. ... >> 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. > > But surely, in most such cases, the right solution is to open an editor > and add the new literals to the original type declaration, isn't it? Perhaps; not so much if this is reusable code and the need is specialized. In any case, changing the type declaration causes errors in lots of code that might be completely unrelated, and it would be good to have a better way to create a new type. (But I think the conversion between semi-unrelated types is a better approach, as it can be used in many ways, not just one.) > The constant assumption in this discussion -- although perhaps not > explicitly stated -- is that we are talking about situations where we want > to keep the parent type around in its original form, and instead derive a > new type, with a specific relationship to the parent type. A valid reason > for this could be, for example, that some operations can be written in > general form on the parent type, and then inherited by several derived > types, or that the same genericity can be got from classwide programming > on Parent'Class. Right. ... >> 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). > > Fair enough, thanks. > > I don't think Dmitry's proposal would cover "deepened" enumeration types, > because there is no natural conversion from the parent type to the > "deepened" type. You're not imaginative enough. ;-) See my previous message. Randy.