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

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Tuck said

<<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.>>

Well things are not as bad as all that, and should be better :-)

Loops need not generate significant inefficiency. Look back to the message
I sent earlier showing how GNAT handles these loops. The overhead is a single
indexed load per loop, not bad at all.

Array indexes should NOT be a problem, if we used the rep value as an index
instead of the pos value as an index. Unfortunately Verdix made what I think
was the wrong implementation choice here, and the Ada 95 RM gives no 
recommendation, so in the absence of any RM advice, we find ourselves
pushed to support Verdix compatibility, and thus introduce the unexpected
inefficiency.

To my mind, it would be better to index by default using the rep value, and
if you want to index by the pos value, do so explicitly!

Succ and Pred are indeed evil :-)

<<So in retrospect, I believe enumeration representation
  clauses in Ada are a mistake.  If a user wants to name
  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.>>



No, I disagree, this is a useful feature that I have often found useful. You
only get the inefficiencies if you use the inefficient constructs, and it 
seems unreasonable to argue that a feature should be removed because someone
might use it inefficiently.

I would say that if I had my choice, I would ban the use of Succ and Pred,
and specify that array indexing was on the basis of pos values. That way
the (relatively) expensive Pos operation would only occur if the programmer
wrote it explicitly.