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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ca9eef4d5e2078ea X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Beware: Rep spec on an enumeration type causes code explosion Date: 1997/12/12 Message-ID: #1/1 X-Deja-AN: 297744345 References: <348F3DFC.10DB@nospam.flash.net> <3490252D.6B550F17@ac3i.dseg.ti.com> X-Complaints-To: usenet@news.nyu.edu X-Trace: news.nyu.edu 881983543 9776 (None) 128.122.140.58 Organization: New York University Newsgroups: comp.lang.ada Date: 1997-12-12T00:00:00+00:00 List-Id: Joe said <> As I said in previous messages, I consider this usage perfectly reasonable. However, it is probably a good idea to consider that such non-contiguous enumeration types should not be used in loops, array indexes, or succ and pred. Indeed a reasonable compromise on the language design issue (Tucker says he would remove them completely) would have been to say that these operations (array indexing, looping, succ and pred) are not available for enumeration types with enumeration representation clauses. You can construct these effects if you like using Pos and Val, but then these operations (with their attendant possible overhead) are explicit.