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,FREEMAIL_FROM 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-02-01 16:06:25 PST Path: supernews.google.com!sn-xit-02!supernews.com!news.tele.dk!130.133.1.3!fu-berlin.de!uni-berlin.de!ppp-4-206.5800-8.access.uk.worldonline.COM!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Re: Extensible Enummerated types FW: When will next Ada revision be? (83, 95, ?) Date: Thu, 1 Feb 2001 22:03:01 -0000 Message-ID: <95ctlj$ff437$1@ID-25716.news.dfncis.de> References: <94c61v$h4a$1@nnrp1.deja.com> <94f9qf$dc4s7$1@ID-25716.news.dfncis.de> <94fdqb$u4b$1@nnrp1.deja.com> <94hr7f$oa0$1@usenet.rational.com> <3A76E923.318F7C1E@averstar.com> NNTP-Posting-Host: ppp-4-206.5800-8.access.uk.worldonline.com (62.64.166.206) X-Trace: fu-berlin.de 981072374 16224359 62.64.166.206 (16 [25716]) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Xref: supernews.google.com comp.lang.ada:4835 Date: 2001-02-01T22:03:01+00:00 List-Id: Following the lead from another poster to this thread, my proposal (and I think this is what the other poster intended) involves no tagging, but is simply as follows. I believe this proposal would be doable and valuable. Let's start with a normal enumeration type declaration, in unit PC_Keyboard: type Key_Value is (A_Key, B_Key, ..., Scroll_Lock); My proposal is that you can make an 'enumeration extension declaration' in any declarative region (AT_Keyboard, say) that has visibility of PC_Keyboard.Key_Value, perhaps like this: type Key_Value is new PC_Keyboard.Key_Value with (F11, F12, ...); Type AT_Keyboard.Key_Value would be in essence an ordinary enumerated type, with all the values of PC_Keyboard.Key_Value plus the extra ones specified (positionally appended). There would be no tag or special indexing. Any representation clause could be applied to it (e.g. changing its size or internal codes). It may need to be made a bigger size (by the compiler if not explicitly) as a result of having more values. One extra rule would be that if PC_Keyboard.Key_Value had an enumeration representation clause (defining its internal codes), then the compiler would demand that AT_Keyboard.Key_Value had one as well (which would have to be comprehensive). I believe the rule (in RM95 13.4(6)) which forces the internal codes to obey the predefined ordering relation should be removed (the compiler would, again, have to use a lookup table if necessary, tough). Some operations would be redefined or added. Conversion from PC_Keyboard.Key_Value to AT_Keyboard.Key_Value would pose no problems (a change of representation may require actual conversion, but this is something Ada already supports). Conversion the other way would also be supported, and would include a check that the value being converted lay within the set of values defined for PC_Keyboard.Key_Value (which would raise Constraint_Error if it failed). There would be overloadings of the "in" operator which allowed a test for a value of one type against a range of the other type, or any subtype thereof. The other operations would all be exactly the same. Plainly, this example declares some extra keys for an AT keyboard, implying that an AT keyboard has at least all the same keys as a PC keyboard. It is better than explicitly redefining all the many PC keys, since there is clearly room for an error creeping in there. It's a better model against the real world. It also simplifies the conversion from one type to another, possibly eliminating another source of error. The implementation would be exactly the same as if one had defined all the values for AT_Keyboard.Key_Value explicitly, apart from the new and different operations (whose implementations are straightforward), and the extra simple rule. QED. PS: Yes I realise that there's not going to be a revision so this kind of idle speculation is pointless, and yes I realise people with nohing better to do ;-) will have a field day picking it apart. Sigh. -- Nick Roberts http://www.AdaOS.org