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.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA 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.234.38 with SMTP id ub6mr8144039pbc.2.1336684952705; Thu, 10 May 2012 14:22:32 -0700 (PDT) Path: pr3ni11247pbb.0!nntp.google.com!news1.google.com!volia.net!news2.volia.net!feed-A.news.volia.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: What would you like in Ada202X? Date: Fri, 11 May 2012 00:22:30 +0300 Organization: Tidorum Ltd Message-ID: References: <3637793.35.1335340026327.JavaMail.geo-discussion-forums@ynfi5> <20780405.1069.1336372385458.JavaMail.geo-discussion-forums@pbkc8> Mime-Version: 1.0 X-Trace: individual.net YJMgXEgo50Cy6P4/1XCxEw5tJhxcfnsJo05gRUm4ecep/d5Qm5yQRSc/KdQmEwc7Up Cancel-Lock: sha1:Sf9R8M3d4Pad5KIIqdlV81Q9kZU= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2012-05-11T00:22:30+03:00 List-Id: 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: > ... >>> It seemed like a useful idea back in the day, >> >> I think that extending enumeration types by "deepening" is a different >> idea than the AI95-261 "widening" idea. Don't you think that they are >> logically different? > > 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. >>> 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. Is there an AI on that? I looked for one, but did not find any. I agree that if a future Ada allows 'Class on Root_Integer (and presumably on most or all other types, too), then "deepened" enumerations would also have to support that. > Inheritance of operations is virtually useless without class-wide > operations. Note that class-wide operations don't necessarily have to > involve dispatching, although that does seem like the most sensible model. > Dmitry has pointed out repeatedly that one does not need to store tags with > values of specific types; they can be added when converted to a class-wide > type and that makes the most sense for elementary and array tagged types. Ok, I see how that can work: you synthesize tags and perhaps other "type descriptors" and pass them as hidden parameters to class-wide operations. (I guess that your experience in implementing code-sharing generics would be useful, no?) >> 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? > (Note that I disagree about call-by-reference, but > that's a detail.) I'd be interested in your view on that, since it seems to bear on the problem of conversions between parent types and "deepened" types. >> 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. Since I respect your opinion very much, I will have to think about class-wide programming for "deepened" enumerations. One problem is that there would be two notions of Enum'Class: 1. If Enum'Class covers only enumeration types derived from Enum using the current Ada derivation method, then the set of literals is the same for all types in Enum'Class. This both simplifies and limits what a class-wide operation can do. 2. If Enum'Class covers also "deepened" enumeration types, then different types in Enum'Class can have completely different sets of literals. However, a class-wide operation can rely on the fact that each literal in Enum corresponds to a range of literals in any type in Enum'Class. There needs to be some way (an attribute function?) to map an Enum value to the range within the actual type of the class-wide parameter. >> Another issue is that generic formal types of the "deepened" kind would be >> needed. I think that would be the next point to work on for this proposal. > > We already have that. Generic derived types (with the ancestor being an > enumeration) would provide the needed inheritance. Not quite, I think, because that has the same limitations as the 1st notion of Enum'Class, above. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .