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.223.40 with SMTP id qr8mr129149pbc.0.1336781511608; Fri, 11 May 2012 17:11:51 -0700 (PDT) MIME-Version: 1.0 Path: pr3ni15420pbb.0!nntp.google.com!news2.google.com!goblin2!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: Fri, 11 May 2012 19:11:44 -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 1336781509 17949 69.95.181.76 (12 May 2012 00:11:49 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sat, 12 May 2012 00:11:49 +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-11T19:11:44-05:00 List-Id: "Niklas Holsti" wrote in message news:a12psmFskuU1@mid.individual.net... > On 12-05-09 01:22 , Randy Brukardt wrote: >> "Niklas Holsti" wrote in message >> news:a0rsroFp8lU1@mid.individual.net... >>> On 12-05-08 03:48 , Randy Brukardt wrote: >> ... >> The details are different, but the basic idea (adding more literals) is >> unchanged. And the use is in adding more literals, the details on exactly >> how you do that are much less important. > > Perhaps I did not describe it well, but I am surprised that you don't see > more difference between "widening" and "deepening". Note that: > > - The "widening" extension only adds literals. The derived type has all > literals of the parent type, plus the added literals. > > - The "deepening" extension *replaces* some parent literals with new > literals. The derived type need not have any literals in common with the > parent type. But each parent-type literal corresponds to a range of > derived-type literals. > > A big difference is that for "widening", there is a natural conversion > (embedding, really) from the parent type to the derived type, while for > "deepening" the natural conversion goes the other way, from the derived > type to the parent type. You are thinking like a language lawyer, much less like a user (something I'm often accused of!). I'm not paying all that much attention to the details of your proposal, but rather trying to look at it as a user would. In that case, both mechanisms give a way to add/change enumeration literals for an existing enumeration type. I think that's the capability that users would want -- and I doubt that they care particularly much how it is accomplished. Of course, the details do matter at some point, but given that it's a number of years before any of this stuff will be worked on very seriously, I'm trying to look at the broad view now. ... >>>> but to be really useful, we >>>> need the equivalent of class-wide operations. >>> >>> That is the main question: do we? >> >> We need class-wide operations for Integer and Float and (especially) >> String, >> so it's hard to imagine how we could avoid needing them for such an >> enumeration! >> >> For example: >> Put (X : in Root_Integer'Class); >> is much more useable than a generic that you have to instantiation for >> each >> kind of type. (Some operations really do cross-cut types.) > > Ah, I didn't realise that you meant such a radical enlargement of the > present tagged-type class-wide programming. If we suddenly have class-wide programming for enumerations, it would be mad to not allow it for other, similar types. > Is there an AI on that? I looked for one, but did not find any. Not really, although I mentioned an off-the-wall proposal for Strings that in an AI in another message from Wednesday. ... >>> It seems to me that adding class-wide operations would force to >>> use some kind of tags, call by reference, and view conversions, and then >>> it becomes so similar to tagged types that it is not worth it. >> >> Umm, that's when it *does* become worth it. The problem is untagged types >> are pretty hard to use. > > Do you mean they are hard to use in current Ada, or hard to use with > class-wide operations in the future Ada? I was thinking of derived untagged types; I should have said that. The issue is that there is virtually no difference between a derived type and two unrelated types with conversion functions. If you call the conversion functions "+" (as some people recommend), you're required to write one whole additional character when using two unrelated types. It's hard to imagine designing the huge mechanism of derived types (with all of its weird problems and compatibility issues) in order to say typing one character per use. (One could even say that the extra typing makes the program more understandable, I'm not sure I'd go that far.) The only thing that you can get from derived types that can't be done any other way is inherit operations (and their interfaces). And that's just short of useless in Ada; the only use you can make of that is via generic derived types. (Moreover, once you add operations to untagged derived types, you can no longer specify their representation, meaning that using them forces you to give up another key Ada feature.) That led me to say: ... >>> I think the idea of "deepened" enumeration types is worth pursuing only >>> if >>> it is useful without class-wide operations. >> >> Then don't bother. IMHO, at least. Randy.