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

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

<<    I'll give you a good reason why getting too smart about rep clause
    implementation might be a Bad Thing. Suppose I implement an
    enumeral type with a "confirming" rep clause because I know I'm
    dealing with a real live hardware interface or message format and
    want to make it clear that the representation for this given
    enumeration is critical. I compile & run and my timing comes out a
    given way because your compiler was smart enough to detect that my
    representation was conveniently matching the positions. So far, so
    good. At a later date the hardware or message format changes to
    include some new bit patterns which create holes in the
    representation and now when I compile I get a significantly
    different implementation for the enumeration and a corresponding
    change in performance. This is a satisfactory definition of the
    technical term: "Bad Thing".

    Sometimes poor performance isn't as bad a Bad Thing as
    inconsistent performance can be.
>>

I don't buy this. A representation with holes is substantially and
fundamentally different from one that does not have holes. Your 
inconsistency problem would still arise if the original program had
not bothered with a rep clause on the grounds that it had no effect.
Surely you don't think all enumeration types should be made horribly
inefficient, just so that in case you add a rep clause with holes
your program does not slow down!