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

[gwinn@res.ray.com (Joe Gwinn)]

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