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/11
Message-ID: <dewar.881901936@merv>#1/1
X-Deja-AN: 297455671
References: <97121110170208@psavax.pwfl.com>
X-Complaints-To: usenet@news.nyu.edu
X-Trace: news.nyu.edu 881902056 12742 (None) 128.122.140.58
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-12-11T00:00:00+00:00
List-Id: <comp.lang.ada>


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