Re: Refactoring and Ada

["Matthew Heaney" <mheaney@on2.com>]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:DRxVLK5K93Eq@eisner.encompasserve.org...
> In article <u6qrqp4dlso46f@corp.supernews.com>, "Matthew Heaney"
<mheaney@on2.com> writes:
> > I don't recommend you use representation clauses for enumeration types.
You
> > should forget this language feature even exists.  Just use integer
constants
> > explicitly.
>
> Why ?
>
> The inability to store an arbitrary numeric value into a location
> whose type is enumerated is one of Ada's greatest strengths.

Here's why:

type ET is (A, B);
for ET use (A => 0, B => 1000000);

A : array (ET) of Integer;

How much storage does array A consume?

Here's another reason:

E : aliased ET;
for E'Size use 8;

read (fd, E'Address, 1);

case E is ...;

What happens when you read junk off the interface?

Below is a post from Tucker on this very subject (courtesy of google):
From: stt@houdini.camb.inmet.com (Tucker Taft)
Subject: Re: Beware: Rep spec on an enumeration type causes code explosion
Date: 1997/12/09
Message-ID: <EKxx9n.Ly1.0.-s@inmet.camb.inmet.com>#1/1
Sender: news@inmet.camb.inmet.com (USENET news)
References: <gwinn-0812971210080001@dh5055133.res.ray.com>
X-Nntp-Posting-Host: houdini.camb.inmet.com
Organization: Intermetrics, Inc.
Newsgroups: comp.lang.ada



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:

: ...
: > As far as enumeration types, as others have pointed out, the Ada 95
: > standard requires that the internal codes for enumeration types are
: > contiguous and start at zero, so you are not in any danger if you leave
: > out your "confirming" representation clauses.  It would be nice if
: > our front end recognized "confirming" enumeration representation
: > clauses, but as usual, there are many possible "optimizations"
: > and this one never made it to the top of the list.
: > One might argue that this is not really an optimization, but
: > it does require special code to recognize, and so represents
: > yet another "special case" that you have to decide the priority
: > of recognizing.

: 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.

[ASIDE:

Although the ability to specify the representation of an enumeration
type initially sounds perfectly reasonable, the fundamental problem is that
Ada also allows such "holey" enumeration types to be used as the
type for a for-loop index, an array index, an entry family index,
or the 'Succ/'Pred attributes.  This results in surprising implicit
inefficiencies, something that violates one of the general Ada
language design principles.  Your enumeration rep clause simply reconfirmed
the default representation, but suppose it didn't?  You would be
stuck with the overhead you managed to eliminate by simply commenting
out the rep clause.  Of course, the compiler could recognize various
other specials cases, such as contiguous representation starting at
something other than zero, or evenly distributed "holey" representation
(e.g., even numbers only), or simply not "too" sparse, or ...

Pretty soon handling these enumeration representation clauses
the way the "innocent" user would "expect" becomes a major artificial
intelligence challenge.  During the Ada 9X design process, when we
found one of our new language ideas evoving into this kind of complex
AI pattern matching problem for the compiler, we knew we were on the
wrong track.  The user should be designing the algorithms, using
the basic primitives of the language.  The primitives shouldn't themselves
be at such a level that the compiler is effectively trying to take over
part of the programming problem.

Note that in C and C++, allowing the user to specify the values for
enumeration literals creates no similar problem, because there is
no operation that depends on the logical "position" of an enumeration
literal.  All semantics of enumeration values in C/C++ depends on the
underlying "code," not the position.

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.

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.

: ...

: Joe Gwinn

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA