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: gwinn@res.ray.com (Joe Gwinn)
Subject: Re: Beware: Rep spec on an enumeration type causes code explosion
Date: 1997/12/12
Message-ID: <gwinn-1212971925480001@dh5055236.res.ray.com>#1/1
X-Deja-AN: 297706097
References: <gwinn-0812971210080001@dh5055133.res.ray.com>
 <EKxx9n.Ly1.0.-s@inmet.camb.inmet.com>
Organization: Raytheon Electronic Systems
Newsgroups: comp.lang.ada
Date: 1997-12-12T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <EKxx9n.Ly1.0.-s@inmet.camb.inmet.com>,
stt@houdini.camb.inmet.com (Tucker Taft) wrote:

> Joe Gwinn (gwinn@res.ray.com) wrote:
> : In article <EKrsrr.LD7.0.-s@inmet.camb.inmet.com>,
> : stt@houdini.camb.inmet.com (Tucker Taft) wrote:
>
> : The key issue was that we had no way of knowing the dire consequences of
> : this innocent looking bit of standard Ada, until we had gone a fair
> : distance down that wrong road.  
> 
> If you ask anyone who knows me well, you will know that I consider
> the enumeration representation clause anything but "innocent looking" ;-).
> For what it is worth, we will soon be releasing a new front end
> that recognizes the special case of a confirming enumeration
> representation clause.

All for the good.  But, we will never know Ada as you have known her.


> [ASIDE:
> 
[snip]
> 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.

I guess I would have to agree, because it's certainly too expensive for
realtime use.  We will invent some such solution as you suggest.


> END OF ASIDE]
> 
> : ... One wonders what other surprises lay in
> : wait.
> 
> In general, the Ada language design philosophy eschewed "innocent"
> looking features that were in fact expensive at run-time.
> However, in the specific case of enumeration representation clauses,
> this useful language design philosophy was not completely followed.
> Other cases I know of are interactions between finalization, 
> exception handling, and abort, where the combination of features
> forces some or all of these three to incur more run-time overhead
> than you might expect.
> 
> One "innocent" looking construct I once found was:
> 
>    (others => Default_Value(Segment))
> 
> used to initialize a segment of a load module to some default value.
> This called the function Default_Value once for each byte of the
> segment, and the segment was often 100K bytes or more.

Thanks for the pointers.  This is just the kind of information we need to
avoid further blunders.

Another one I knew of from before was tick-Image, which triggered
formatted conversion.  Text-IO also.  I have been forbidding the use of
formatted I/O in realtime from the 1970s, in fortran.  


Joe Gwinn