Re: Beware: Rep spec on an enumeration type causes code explosion

["Stanley R. Allen" <s_allen@hso.link.com>]

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