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: "Stanley R. Allen" Subject: Re: Beware: Rep spec on an enumeration type causes code explosion Date: 1997/12/10 Message-ID: <348F3238.4487@hso.link.com>#1/1 X-Deja-AN: 297071585 References: Organization: NASA, Kennedy Space Center Newsgroups: comp.lang.ada Date: 1997-12-10T00:00:00+00:00 List-Id: Tucker Taft wrote: > > Although the ability to specify the representation of an enumeration > type initially sounds perfectly reasonable, the fundamental problem is that > Ada also allows such "holey" enumeration types to be used as the > type for a for-loop index, an array index, an entry family index, > or the 'Succ/'Pred attributes. This results in surprising implicit > inefficiencies, something that violates one of the general Ada > language design principles. I find it hard to believe that the efficiency of this is *implictly* bad. It seems like the use of holey enum types for for-loop ranges, array-indexes, etc, would always default to the use of positions; only placing the enum value into a location should cause a table look-up (one index redirection) for the actual value. > > So in retrospect, I believe enumeration representation > clauses in Ada are a mistake. If a user wants to name > particular values, they should simply use named integer > constants, or perhaps better, named private-type constants. They can build > up various maps of their own if they want to translate to/from some kind > of "holey" representation from/to a contiguous representation. > But then you lose the 'Image function, 'Range, array index, etc., which is why you wanted the Enum type to begin with! (I understand that I can simulate some of this.) I'm not surprised to hear Tucker say this, however, since he has complained publicly before that "those chapter 13 features end up being 50% of your compiler!"; I'm sure compiler developers would like some relief from having to expend so much effort on those aspects. -- Stanley Allen mailto:s_allen@hso.link.com