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,ce896fd16cf323ae X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!not-for-mail From: Nick Roberts Newsgroups: comp.lang.ada Subject: Re: Enumeration representation enhancement proposal Date: Thu, 14 Oct 2004 18:47:19 +0100 Message-ID: <2t7sd8F1rsqh9U1@uni-berlin.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de DVkU8EW53Uh2jQII8SY/0wJC4NRtAr99glpAcL+4q2v/iAK0Q= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en In-Reply-To: Xref: g2news1.google.com comp.lang.ada:5212 Date: 2004-10-14T18:47:19+01:00 List-Id: Wojtek Narczynski wrote: > Enumeration representation in their current form are not very useful, > because there is no treatment of invalid values. That's why constants, > and constant to enum mapping arrays are used so heavily in real > interfacing code. I tentatively agree with this sentiment. However, I suspect that making enumeration types more 'useful' could be difficult. > Invalid external values are rather norm than exception, thus they > deserve 'non-exceptional' treatment. The 'Valid attribute alleviates > the problem, but it is not very convenient, for example won't work in > case statements, it requires to have two different ways to log the > value (valid and invalid). > > Maybe this could be improved in Ada 2005? For example: > > type Mix_Code is (Red, Green, Blue, Grey); > > -- Modest proposal > > for Mix_Code use (Red => 1, Green => 2, Blue => 3, Grey => others); > > This should be relatively straightforward to implement, and would cover > most needs. The problem with this proposal it that (actual) values of the type would no longer satisfy the ordering criteria (that a machine < or > test will always have the same result as the corresponding canonical test). > However... > > -- Die-hard proposal > > for Mix_Code use > (Red => 1 | 10, Green => 11 .. 20, Blue => 21 .. 30 | 40, Grey => others); > > An unambiguous mapping from the rep value to Ada enum would be required, > not the other direction. This idea seems to stir up a hornet's nest of difficulties. I also suspect that if the ordering property were still required, it wouldn't often be useful in practice. I think I'd rather construct a type with explicit operations to deal with this sort of situation; this approach does give complete control over the translation between (actual) value and meaning. But this is just my opinion! Unfortunately, I believe it is now too late for any new proposals for Ada 2005. I think there is just one more ARG meeting before they must put their recommendation to WG9 (the committee of representatives of the respective members of ISO delegated to deal with the Ada language). WG9 will vote on each amendment proposal, and they will (almost certainly) reject any proposal that they feel has not been properly developed. (In other words, crunch time.) I'm not quite sure about the schedule TBH. -- Nick Roberts