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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5b0235b23a9db0f2 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-01-22 09:45:57 PST Path: supernews.google.com!sn-xit-02!supernews.com!nntp-relay.ihug.net!ihug.co.nz!newsfeed.mesh.ad.jp!osa.uu.net!sac.uu.net!usenet.rational.com!not-for-mail From: "Mark Lundquist" Newsgroups: comp.lang.ada Subject: Re: Extensible Enummerated types FW: When will next Ada revision be? (83, 95, ?) Date: Mon, 22 Jan 2001 09:26:01 -0800 Organization: Rational Software Message-ID: <94hr7f$oa0$1@usenet.rational.com> References: <94c61v$h4a$1@nnrp1.deja.com> <94f9qf$dc4s7$1@ID-25716.news.dfncis.de> <94fdqb$u4b$1@nnrp1.deja.com> NNTP-Posting-Host: ext-3087.rational.com X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Xref: supernews.google.com comp.lang.ada:4325 Date: 2001-01-22T09:26:01-08:00 List-Id: Robert Dewar wrote in message news:94fdqb$u4b$1@nnrp1.deja.com... > In article <94f9qf$dc4s7$1@ID-25716.news.dfncis.de>, > "Nick Roberts" wrote: > > I like this idea. It seems to me that it could be really > useful sometimes > > (enough to justify it). It also seems to me that there would > be no major > > implementation problem. It would require a number of changes > and insertions > > to the RM, but nothing drastic. Gets my vote. > > I assume you have studied the proposal in the mapping document > and it is to this proposal that you are referring. > BTW, where can we find this mapping document? It'd be especially nice if there were an HTML version somewhere... (Someone has also said that it would be nice if the AI database were more Web-friendly, and I concur). Anyway, back to the extended enumeration type thing... for my part, I haven't read the proposal in the mapping document (since I don't have it :-), so someone needs to tell me what the feature means in that proposal. Also, I'm not entirely clear what people are asking for, so even if I did know what the idea was as it was proposed in the 9x process, I still wouldn't know if that's the same thing :-) What I want to know is... Given type E1 is (Dog, Cat); type E2 is new E1 with (Kangaroo); I understand what this is supposed to mean in terms of E2's enumeration literals. What's not clear to me is whether E2 is supposed to have any particular relationship to E1. The only meaninful relationship I can think of would be the derivation class -- the implication would be that the enumeration types are tagged. In that case, you obviously have to know that E1 is tagged. Since the syntax of its definition is identical to the current syntax for enumeration type definitions, then either (a) the idea is that all enumeration types be tagged (not likely! :-) or (b) people aren't really asking to do classwide programming on enumeration types after all, or (c) they are asking for that but haven't thought it through very far :-) :-) A nice Ada syntax for expressing taggedness of an enumeration type escapes me right now... I guess it would have to be tagged type E1 is (Dog, Cat); If we're not asking for taggedness/classwide, then E1 and E2 have absolultely no relationship to each other except that they happen to have some of the same enumeration literals, right? In other words, the second line above is precisely equivalent to saying, type E2 is (Dog, Cat, Kangaroo); in current Ada, with no extra baggage. In that case, the proposal is just for some syntactic sugar, correct? So what is it, sugar or classwide? :-) If it's classwide, what I would really like to see is a specific example, in Ada code, of a problem that would be solved by the proposed feature... - mark