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/08
Message-ID: <gwinn-0812971144210001@dh5055133.res.ray.com>#1/1
X-Deja-AN: 296314670
References: <gwinn-0512972303070001@dh5055063.res.ray.com>
 <dewar.881405297@merv>
Organization: Raytheon Electronic Systems
Newsgroups: comp.lang.ada
Date: 1997-12-08T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <dewar.881405297@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

> Joe said
> 
> <<I suppose that the writers of Ada95 compilers know where they struggled
> with Ada95, as well as Ada83 before it.  If it was hard for them to write,
> it will likely generate lots of code.
> >>
> 
> Not necessarily, I don't see any real relationship between difficulty
> of implementation and amount of code generated. For example, private
> types remain one of the most difficult areas of Ada 95 to implement
> correctly (Tuck once said that the hard parts of Ada 95 from an
> implementors point of view all come from Ada 83 :-) Yet private types
> of course generate no code at all in most cases.
> 
> Similarly, generics are very hard to get right, but this does not mean
> that lots of unnecessary code is generated.
> 
> On the other hand, most (but not all) of the processing for enumeration
> types with holes is quite straightforward, but surprised Joe with the
> amount of code generated (actually that might not be quite fair, from the
> sound of it, it could be the case that the compiler was in that case
> generating more code than is justified).

I don't doubt that there are counterexamples, but still I bet that the
people who wrote the compilers have a pretty good idea which idioms are
likely to lead to code explosions, and which are not likely to explode,
and can tell us what the relative costs are likely to be.  I'm sure they
thought that part of the compiler quite ugly, for the gyrations they were
for one reason or another forced to perform.

Great precision is not required.  The point is to avoid project-killing
100:1 effects, not to trim 10% somewhere.

Joe Gwinn