Re: Beware: Rep spec on an enumeration type ...

Re: Beware: Rep spec on an enumeration type ...

[Matthew Heaney]

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


>That being said, there are definitely some areas where Joe's wish for some
>standardized advice would be useful. For example, all Ada programmers should
>understand the two models of implementing variant records with default
>discriminant values, and all Ada programmers should be aware of the 
>consequences of using controlled types.

Robert, how about elaborating on these points?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Beware: Rep spec on an enumeration type ...

[Joe Gwinn]

Green Hills informs me that unnamed Ada vendors have been misusing my 5
December 1997 posting "Beware: Rep spec on an enumeration type causes code
explosion" (on newsgroup "comp.lang.ada") to gain unfair competitive
advantage, in effect claiming that my posting proves that the Green Hills
Ada95 compiler is relatively immature, that only Green Hills has such
problems, etc.  I very much disagree with this interpretation.  My
interpretation follows.


All this talk of "maturity" in compilers for a very complex language
finalized only two years ago, in 1995, strikes me as painfully naive.  All
living compilers are works in progress.   They all have their strong
points and weak points, some common to all compilers, and some particular
to one or another compiler, and all will have their fair share of
pratfalls. This is true of C++ and Ada95, which are of roughly equal
complexity.  It's misleading to say or imply otherwise.  

So, if a vendor foolishly claims such perfection, laugh, and ask to see
his buglist.  Yes, he does most certainly does have one.  It may prove
difficult to get a copy.

Also ask for the names and phone numbers of ten happy users of the
compiler, call them up, and ask them how just how happy they are.  If no
such list is forthcoming, find another vendor.  We are judged by the work
of our hands.


More to the point, my complaint here is with the entire Ada community, and
not with this or that specific vendor or compiler.  What's needed is an
efficient way for mere customers to gracefully avoid the inevitable
pratfalls, rather than to be forced find them in the dark one by one, with
their shins.  Expensive, painful, and embarassing.  

There is a rule of thumb in retail that every satisfied customer tells
perhaps two people, while every dissatisfied customer tells at least ten
people.  Every horror story shrinks the Ada market.  

It does nobody any good to allow Ada's reputation to be damaged by
allowing one Ada customer after another to blunder into such well-known
beartraps.  Most customers are domain experts, not language experts. 
Telling them after the fact that they should have known better just makes
them angrier and angrier, and drives them away.

Tucker Taft's posting of 9 December 1997, which gave a number of areas to
look into, is just the kind of pointed information that is needed, and can
form the start of an Ada95 FAQ.  What other areas are known?  Let's pull a
FAQ together, starting now.  Please email me a copy of all relevant
postings.


Joe Gwinn

Re: Beware: Rep spec on an enumeration type ...

[Robert Dewar]

Joe said

<<Green Hills informs me that unnamed Ada vendors have been misusing my 5
  December 1997 posting "Beware: Rep spec on an enumeration type causes code
  explosion" (on newsgroup "comp.lang.ada") to gain unfair competitive
  advantage, in effect claiming that my posting proves that the Green Hills
  Ada95 compiler is relatively immature, that only Green Hills has such
  problems, etc.  I very much disagree with this interpretation.  My
  interpretation follows.>>

It is a silly and risky thing for vendors to jump on one particular difference
like this, and claim that it represents a general state of things. As Joe
says in his message, every compiler has particular problem areas. Yes, sure
salesmen go around seizing on such things, and I suppose it must work in some
cases or why would they do it? For example, we know of a case where one
particular program did not compile on GNAT, but compiled using compiler X.
The salesman for X showed this off as an example of the supposed "immaturity"
of GNAT -- one slight glitch -- GNAT happened to be right, and this was in
fact a long standing bug in compiler X :-)

You will always be able to find relative weaknesses and strengths when
comparing any two compilers. In a benchmark of GNAT against a compiler
that has been around for a while, the performance was generally comparable
with a few exceptions. A salesman could focus on one line in such a bench
mark result "Look here, GNAT is ten times slower on this program than xxx".
Of course a GNAT salesman (if there were such a beast :-) could pick another
test and say exactly the opposite. Both are true statements, neither is
helpful.

I actually think that more important than whether glitches exist is the
support a vendor gives in helping you find and fix glitches. To me, one
of the nice things about the specific discussion of enumeration types was
the note from Intermetrics that the next version of the compiler would
indeed fix the failure to recognize the confirming rep clause as a special
case. It's that kind of responsiveness that users really need, and in this
case will get.

<<It does nobody any good to allow Ada's reputation to be damaged by
  allowing one Ada customer after another to blunder into such well-known
  beartraps.  Most customers are domain experts, not language experts.
  Telling them after the fact that they should have known better just makes
  them angrier and angrier, and drives them away.>>

Well I must say this giant population of angry Ada users who don't know
what they are doing must either be smaller than Joe thinks, or they must
not be using GNAT :-)

Seriously, I think Joe way overstates the problem here. Perhaps his shop has
just had bad luck, but I think the kind of problem he worries about is a
relatively minor issue in the overall success picture of the use of Ada.
You do not have to be a language expert to have the background to have a
feeling for many of these issues. A basic graduate course in programming
language design and compiler techniques, should be quite adequate, the
sort of education that any CS graduate should have. If you have an entire
project with no one with this kind of background, then I think that is
definitely asking for trouble!

That being said, there are definitely some areas where Joe's wish for some
standardized advice would be useful. For example, all Ada programmers should
understand the two models of implementing variant records with default
discriminant values, and all Ada programmers should be aware of the 
consequences of using controlled types.

Robert Dewar
Ad Core Technologies

Re: Beware: Rep spec on an enumeration type ...

[Joe Gwinn]

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

> I actually think that more important than whether glitches exist is the
> support a vendor gives in helping you find and fix glitches. To me, one
> of the nice things about the specific discussion of enumeration types was
> the note from Intermetrics that the next version of the compiler would
> indeed fix the failure to recognize the confirming rep clause as a special
> case. It's that kind of responsiveness that users really need, and in this
> case will get.

Support after the blunder is very nice, but it's a lot less painful if we
can avoid the blunder in the first place.  And, my complaint was never
about lack of post-blunder support.


> <<It does nobody any good to allow Ada's reputation to be damaged by
>   allowing one Ada customer after another to blunder into such well-known
>   beartraps.  Most customers are domain experts, not language experts.
>   Telling them after the fact that they should have known better just makes
>   them angrier and angrier, and drives them away.>>
> 
> Well I must say this giant population of angry Ada users who don't know
> what they are doing must either be smaller than Joe thinks, or they must
> not be using GNAT :-)

Well, let me tell you another saying from the retail world:  For every
customer that complains, there are ten who will simple never come back. 
Silence is not golden.


> Seriously, I think Joe way overstates the problem here. Perhaps his shop has
> just had bad luck, but I think the kind of problem he worries about is a
> relatively minor issue in the overall success picture of the use of Ada.

Of course we were in a sense unlucky, but ...  On a project of any size,
the language will be well explored, and most such blunders will be made
somewhere, so it isn't really a matter of luck.


> You do not have to be a language expert to have the background to have a
> feeling for many of these issues. A basic graduate course in programming
> language design and compiler techniques, should be quite adequate, the
> sort of education that any CS graduate should have. If you have an entire
> project with no one with this kind of background, then I think that is
> definitely asking for trouble!

Well, this certainly allows us to size the problem:  One must have a
graduate degree in language design and compiler techniques to use Ada. 
That's quite a revelation.  We would have never suspected that Ada was
that hard to use.

This gets to the heart of the problem.  Our programmers, being domain
experts, would rather take graduate degrees in their respective fields of
interest, in their chosen professions.  If they were interested in being
compiler experts, they would have instead studied compilers, and they
would probably work for a compiler vendor, not a system vendor, because
few system vendors build compilers.  Nor would they be experts at other
than compilers; there are only so many hours in the day.  Domain expert
and compiler expert are very different fields.


> That being said, there are definitely some areas where Joe's wish for some
> standardized advice would be useful. For example, all Ada programmers should
> understand the two models of implementing variant records with default
> discriminant values, and all Ada programmers should be aware of the 
> consequences of using controlled types.

This sounds interesting.  Could you expound further?


Joe Gwinn

Re: Beware: Rep spec on an enumeration type ...

[Robert Dewar]

Joe said

<<Well, let me tell you another saying from the retail world:  For every
  customer that complains, there are ten who will simple never come back.
  Silence is not golden.>>

Ah, but we never get silence. Our product is immediate response to questions
and problems, and our customers most certainly take advantage of this. Silence
is not something we get (or expect) from our customers! This is quite a 
different situation from most software vendors, where they get their money
from selling you stuff, and hope you don't call. We hope you will call, so
that you see how valuable to the support is, and most of our customers
most definitely take advantage of this.

<<Well, this certainly allows us to size the problem:  One must have a
  graduate degree in language design and compiler techniques to use Ada.
  That's quite a revelation.  We would have never suspected that Ada was
  that hard to use.

  This gets to the heart of the problem.  Our programmers, being domain
  experts, would rather take graduate degrees in their respective fields of
  interest, in their chosen professions.  If they were interested in being
  compiler experts, they would have instead studied compilers, and they
  would probably work for a compiler vendor, not a system vendor, because
  few system vendors build compilers.  Nor would they be experts at other
  than compilers; there are only so many hours in the day.  Domain expert
  and compiler expert are very different fields.>>

First, Joe has a giant misconception. There is a HUGE gap between taking
a basic course in programming languages and compiler construction at the
graduate level and being an expert, or having a graduate degree in the
subject. Sounds like Joe does not have much familiarity with CS as a
discipline so perhaps this confusion is understandable, but this is a bit
like thinking taking the first graduate physics course turns you into an
expert in particle physics, Sorry it ain't so.

Second, I think he is right, this does get to the heart of the problem. Sounds
like the projects Joe is involved in are making the mistake of trying to build
big programs using ONLY domain experts. That might have worked in Fortran with
simple numerical stuff in the 60's, but it is a major mistake at this stage,
when even scientific programming more and more is getting into the realm of
highly complex algorithms. 

To think that you can be a domain expert and pick up what you need to know
about programming by reading a few FAQ's is as silly as as computer scientist
thinking they can become an expert in physics by reading some "helpful hints
about nuclear physics" FAQ.

What you need these days is a mixture of people who know the domain well, and
programming some, and people who know programming well, and the domain some.
By programming here, I mean the union of language, compiler, software
engineering, design etc knowledge that is required these days to construct
complex systems.

I cetainly am not saying that the only way to get this knowledge is to take
CS courses (my background is a PhD in chemistry, although I did take a couple
of grad courses in Computer Science, one in compilers). Certainly there
are people who not only have the basic knowledge corresponding to these
subject areas, but are world-class experts in these areas, who have NOT
taken courses, but for most people the path to this kind of knowledge is
a specialized higher degree.

Now from reading what Joe has said, the folks in his group simply lack this
kind of knowledge, and they get into trouble because of it. That is not at
all surprising, and I am afraid it will not be corrected by reading a few
posts on CLA. 

Note also that this is nothing to do with Ada. Whether you are programming in
Fortran-66 or C, or one of the newer more complex languages such as C++ or
Fortran-90, you need to know what you are doing. Some of the worst applications
code I have seen has been hacked together by experts in their areas who clearly
have a dismal knowledge of how to program. Often they have the form, but not
the substance, I have seem beautifully laid out and documented implementations
of perfectly horrible and inappropriate algorithms.

One of my favorites was a routine to convert from lower case letters to
upper case letters. I will try to reproduce it from memory. It was something
like:

  function Convert_Lower_Case_Letter_To_Upper_Case_Letter
    (Input_Character : Character) return Character is
  
  -- (piles of documentation about preconditoins and postconditions etc)
  
    subtype Letter_Range is Natural range 1 .. 26;
  
    type Letter_Array is array (Letter_Range) of Character;
    Lower_Case_Letters : Letter_Array := (1 => 'a',
                                          ...
  
  --  (piles of helpful comments throughout, beautifully formatted)
  
    Upper_Case_Letters : Letter_Array := (1 => 'A',
  
  begin
     for Character_Index in Letter_Range loop
        if Input_Character = Lower_Case_Letters (Character_Index) then
           return Upper_Case_Letters (Character_Index);
        end if;
     end loop;
  
     raise Character_Is_Not_Lower_Case;
  
  exception
     when Constraint_Error =>
        raise Convert_Lower_Case_Letter_To_Upper_Case_Letter_Constraint_Error;
  
  end Convert_Lower_Case_Letter_To_Upper_Case_Letter;

The sad thing is that the programmer who wrote this probably thought they
were doing a good job. Certainly this is a nice example of A for effort,
F for content.

I should say that I see this mistake made FAR less often these days. Most
big projects I am familiar with do indeed have a mixture of folks with
different backgrounds, some domain experts, some more expert in the technical
aspects of programming, who work well together. This approach is very
effective. Joe's group should give it a try :-)

Joe, you really *have* put your finger on it. What we have here is a situation
of a bunch of architects designing a house, and then figuring they can do the
carpentry themselves even though they are not expert carpenters. All they need
to do is to go to alt.carpentry.helpful_hints, and read the FAQ, and they
will be fine. When they fail, they complain that obviously it is absurd that
tools like saws require experts to use them, and that saw experts could not
possibly design houses!

Robert Dewar
Ada Core Technologies

Re: Beware: Rep spec on an enumeration type ...

[Joe Gwinn]

We are again in one of these circular discussions.   I don't think I can
explain it any better than I already have, so I'm not going to try.  

I will summarize my point:

One can go on and on about what people should or should not do, but I very
much doubt that our immediate customer will ever use Ada again.  It
matters not at all if they are right or wrong; as our customers, they are
by definition right, and we will do as they ask.  What they see is zero
trouble with C, but lots of trouble with Ada.  

I have been trying to report how it works in the world, and all I get is
yards of text trying to convince us that because the belief is wrong, they
cannot think as they think.  Well, think again.  It doesn't really matter
if they're wrong, they're tired of surprises and expenses, and C/C++
beckons.  It may be that C/C++ is all hype, but it's certainly effective
hype.

What one would have hoped for here was focused effort on solving the
problems that are driving customers away, not an argument claiming that
there is no problem, or that everybody is stupid, too stupid to use Ada.  

On the other hand, perhaps you're right, and, in view of their limited
capabilities, they should run immediately to a language simple enough for
them to handle?

Joe Gwinn



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

> Joe said
> 
> <<Well, let me tell you another saying from the retail world:  For every
>   customer that complains, there are ten who will simple never come back.
>   Silence is not golden.>>
> 
> Ah, but we never get silence. Our product is immediate response to questions
> and problems, and our customers most certainly take advantage of this. Silence
> is not something we get (or expect) from our customers! This is quite a 
> different situation from most software vendors, where they get their money
> from selling you stuff, and hope you don't call. We hope you will call, so
> that you see how valuable to the support is, and most of our customers
> most definitely take advantage of this.
> 
> <<Well, this certainly allows us to size the problem:  One must have a
>   graduate degree in language design and compiler techniques to use Ada.
>   That's quite a revelation.  We would have never suspected that Ada was
>   that hard to use.
> 
>   This gets to the heart of the problem.  Our programmers, being domain
>   experts, would rather take graduate degrees in their respective fields of
>   interest, in their chosen professions.  If they were interested in being
>   compiler experts, they would have instead studied compilers, and they
>   would probably work for a compiler vendor, not a system vendor, because
>   few system vendors build compilers.  Nor would they be experts at other
>   than compilers; there are only so many hours in the day.  Domain expert
>   and compiler expert are very different fields.>>
> 
> First, Joe has a giant misconception. There is a HUGE gap between taking
> a basic course in programming languages and compiler construction at the
> graduate level and being an expert, or having a graduate degree in the
> subject. Sounds like Joe does not have much familiarity with CS as a
> discipline so perhaps this confusion is understandable, but this is a bit
> like thinking taking the first graduate physics course turns you into an
> expert in particle physics, Sorry it ain't so.
> 
> Second, I think he is right, this does get to the heart of the problem. Sounds
> like the projects Joe is involved in are making the mistake of trying to build
> big programs using ONLY domain experts. That might have worked in Fortran with
> simple numerical stuff in the 60's, but it is a major mistake at this stage,
> when even scientific programming more and more is getting into the realm of
> highly complex algorithms. 
> 
> To think that you can be a domain expert and pick up what you need to know
> about programming by reading a few FAQ's is as silly as as computer scientist
> thinking they can become an expert in physics by reading some "helpful hints
> about nuclear physics" FAQ.
> 
> What you need these days is a mixture of people who know the domain well, and
> programming some, and people who know programming well, and the domain some.
> By programming here, I mean the union of language, compiler, software
> engineering, design etc knowledge that is required these days to construct
> complex systems.
> 
> I cetainly am not saying that the only way to get this knowledge is to take
> CS courses (my background is a PhD in chemistry, although I did take a couple
> of grad courses in Computer Science, one in compilers). Certainly there
> are people who not only have the basic knowledge corresponding to these
> subject areas, but are world-class experts in these areas, who have NOT
> taken courses, but for most people the path to this kind of knowledge is
> a specialized higher degree.
> 
> Now from reading what Joe has said, the folks in his group simply lack this
> kind of knowledge, and they get into trouble because of it. That is not at
> all surprising, and I am afraid it will not be corrected by reading a few
> posts on CLA. 
> 
> Note also that this is nothing to do with Ada. Whether you are programming in
> Fortran-66 or C, or one of the newer more complex languages such as C++ or
> Fortran-90, you need to know what you are doing. Some of the worst
applications
> code I have seen has been hacked together by experts in their areas who
clearly
> have a dismal knowledge of how to program. Often they have the form, but not
> the substance, I have seem beautifully laid out and documented implementations
> of perfectly horrible and inappropriate algorithms.
> 
> One of my favorites was a routine to convert from lower case letters to
> upper case letters. I will try to reproduce it from memory. It was something
> like:
> 
>   function Convert_Lower_Case_Letter_To_Upper_Case_Letter
>     (Input_Character : Character) return Character is
>   
>   -- (piles of documentation about preconditoins and postconditions etc)
>   
>     subtype Letter_Range is Natural range 1 .. 26;
>   
>     type Letter_Array is array (Letter_Range) of Character;
>     Lower_Case_Letters : Letter_Array := (1 => 'a',
>                                           ...
>   
>   --  (piles of helpful comments throughout, beautifully formatted)
>   
>     Upper_Case_Letters : Letter_Array := (1 => 'A',
>   
>   begin
>      for Character_Index in Letter_Range loop
>         if Input_Character = Lower_Case_Letters (Character_Index) then
>            return Upper_Case_Letters (Character_Index);
>         end if;
>      end loop;
>   
>      raise Character_Is_Not_Lower_Case;
>   
>   exception
>      when Constraint_Error =>
>         raise Convert_Lower_Case_Letter_To_Upper_Case_Letter_Constraint_Error;
>   
>   end Convert_Lower_Case_Letter_To_Upper_Case_Letter;
> 
> The sad thing is that the programmer who wrote this probably thought they
> were doing a good job. Certainly this is a nice example of A for effort,
> F for content.
> 
> I should say that I see this mistake made FAR less often these days. Most
> big projects I am familiar with do indeed have a mixture of folks with
> different backgrounds, some domain experts, some more expert in the technical
> aspects of programming, who work well together. This approach is very
> effective. Joe's group should give it a try :-)
> 
> Joe, you really *have* put your finger on it. What we have here is a situation
> of a bunch of architects designing a house, and then figuring they can do the
> carpentry themselves even though they are not expert carpenters. All they need
> to do is to go to alt.carpentry.helpful_hints, and read the FAQ, and they
> will be fine. When they fail, they complain that obviously it is absurd that
> tools like saws require experts to use them, and that saw experts could not
> possibly design houses!
> 
> Robert Dewar
> Ada Core Technologies

Re: Beware: Rep spec on an enumeration type ...

[Dale Stanbrough]

"Well, this certainly allows us to size the problem:  One must have a
 graduate degree in language design and compiler techniques to use Ada. 
 That's quite a revelation.  We would have never suspected that Ada was
 that hard to use.
 
 This gets to the heart of the problem.  Our programmers, being domain
 experts, would rather take graduate degrees in their respective fields of
 interest, in their chosen professions.  If they were interested in being
 compiler experts, they would have instead studied compilers, and they
 would probably work for a compiler vendor, not a system vendor, because
 few system vendors build compilers.  Nor would they be experts at other
 than compilers; there are only so many hours in the day.  Domain expert
 and compiler expert are very different fields."


I think this is a rather pessimisstic intrepretation of what Robert said.
Robert's point, which I agree with, is that if you want to use tools in
your job, you have to understand how to use them, and what their
limitations are.

For example imagine someone who wishes to make films. "I've been to 
director's school, I know how to direct, why do I need to know anything
about how video/film camera's work?". Yet I'm sure you would agree that
you can't film someone with the sun directly in the lens. What about
flare from lights? What other restrictions are there that are placed on
a director by technical limitiations?

Using any technology without understanding it is just inviting disaster,
and this is shown out by your own experience. Yes your software "worked",
but it got tripped up by a bad implementation (it was slower than it
should have been). At the Melbourne TOOLS conference a few years back 
Roger Osmond spoke about his team's experience using Eiffel in building
a data comms box (he was very enthusiastic). However initially his team
found that the software was unbelievably slow because they were 
continually allocating memory, and leaving it to be cleaned up by the 
GC system. In the end the domain experts needed to understand the 
consequences of unfettered allocation in such an environment. They 
needed to understand the technology to be able to use it constructively.

As to your other point, attending a compiler construction course does
not mean you will be a compiler writer - it just means you are familiar
with the issues. It would be helpful if so many more students _did_
attend these classes by the way - it would often help dispel the
"while (!(*p)) { *q++ = *p++} must be more efficient than an Ada for
loop" myth.


Dale

Re: Beware: Rep spec on an enumeration type ...

[Robert Dewar]

Joe says

<<What one would have hoped for here was focused effort on solving the
problems that are driving customers away, not an argument claiming that
there is no problem, or that everybody is stupid, too stupid to use Ada.

On the other hand, perhaps you're right, and, in view of their limited
capabilities, they should run immediately to a language simple enough for
them to handle?
>>

There is no such thing as a language simple enough for people who don't know
what they are doing to handle. Actually, simplicity is a tricky thing. If
you go for a simple language, i.e. one with few features, then you may find
that you have to fiddle to do straightforward things. For example, if you
need exceptions, which would you prefer, the structured features of Ada
exceptions, or messing with setjmp/longjmp? (anyone who thinks that C is
immune from complex features whose efficienty depends on the implementation
should spend some time studying the various implementations of setjmp/longjmp).

Similarly, the advice that successful projects need close cooperation between
domain experts, and people who understand the tools, and details of basic
computer science, applies regardless of the language being used. I have
seen complete chaos created by people who know the problem area but do
not have the necessary programming skills in Fortran, C, COBOL and virtually
all other programming languages.

Joe, I still get the feeling that your insistence on the idea that the entire
project should be staffed with domain experts, and your dismissal of the
suggestion that it would be helpful to have people whose primary expertise
was in software engineering, is the crux of your problem. Certainly you
are having problems that I do NOT see other groups having, and my analysis
is that this is the real source of the problem.

You ask above for a "focused effort .. solving the problems ...", but you
have in mind that the solution is to build an FAQ which will provide
simplistic rules (e.g. "never use formatted IO") that will magically solve
your problems. Sorry, I don't think this is feasible!

Re: Beware: Rep spec on an enumeration type ...

[Dale Stanbrough]

An interesting posting on this very issue from a few years ago...


From: emery@goldfinger.mitre.org (David Emery)
Newsgroups: comp.lang.ada
Subject: Re: UNCHECKED_CONVERSION
Date: 24 Jan 94 16:11:44
Organization: The Mitre Corp., Bedford, MA.

The 'right way' to do such things is to completely avoid
representation specs on the enumeration type, and use mapping arrays,
(The following has not been compiled, but should be considered as an
'outline' of the actual approach...)

-- public (package spec)

	type color is (r,g,b);

	function int_to_color (int : integer)
	    return color;
	function color_to_int (c : color)
	    return integer;

-- private (package body)

	subtype color_values is integer range 1..5;

	type int_color_element (valid : boolean := false) is
	  record
	    case valid is
	      when true => c : color;
	      when others => null;
	    end case;
	  end record;
	
	color_to_int_map : array (color) of integer
	          := (r => 1, g => 3, b => 5);
	int_to_color_map : array (color_values) of color
		  := (1 => (true, r), 2 => (false), 3 => (true, g),
		      4 => (false), 5 => (true, b));
	  -- note: This may require qualified notation, etc, to compile.
		
	function int_to_color (int : integer)
	    return color
	is
          answer : int_color_element;
	begin
	  answer := int_to_color_map (int);
	  if answer.valid then
	    return answer.c;
	  else
	    raise Constraint_Error;
	  end if;
	exception
	  when others => 
	    raise constraint_error;	
	end int_to_color;

	function color_to_int (c : color
	    return integer
	is 
	begin
	  return color_to_int_map (c);
	end color_to_int;

There are several advantages with this approach.  First is that all
representation information is encoded in the package body, and not in
the specification.  This makes it much easier to change the underlying
representation without breaking the existing code.  Also, note that
Constraint_Error is raised for out-of-value integers, preserving the
basic Ada semantics of type conversion.  

Second, it's portable, and doesn't depend on any unchecked_conversion
semantics.  It's also type-safe, if you go to the effort (as shown) to
check the incoming integer value.  (Unchecked_Conversion of the value
"4" for instance, would result in an erroneous program.)

This costs a couple of extra instructions, but the type safety, etc,
is well worth it.  For large enumeration types, there are plenty of
search and validation techniques.   See your favorite data structures
book :-)

I discuss this (with more reasons why this is the right solution) in
my paper on my POSIX/Ada port, Proceedings Tri-Ada '90.

				dave

-----------------
Dale

Re: Beware: Rep spec on an enumeration type ...

[Dale Stanbrough]

Robert Dewar writes:

"You ask above for a "focused effort .. solving the problems ...", but you
 have in mind that the solution is to build an FAQ which will provide
 simplistic rules (e.g. "never use formatted IO") that will magically
solve
 your problems. Sorry, I don't think this is feasible!"


...but an FAQ that says "most of Ada is pretty predicatable, and like
most other languages (e.g. loops, if statements), but watch out for these
bits, they can be tricky and have unforseen consequences" would be
useful."
(i'm writing one right now, actually :-)

Besides such lists allow people to understand better what Ada is about,
depending on the coverage (e.g. it could also cover things such as
"a package is not a type", as one review a year or two back managed to 
get wrong (still!)).


Dale