Re: Printing Enum Variable Re: Linux World

[kilgallen@eisner.decus.org (Larry Kilgallen)]

In article <7c3lft$t10$1@remarQ.com>, "Michael Young" <nobody@all.org> writes:
> Richard D Riehle <laoXhai@ix.netcom.com> wrote in message
> news:7c1833$2n@sjx-ixn6.ix.netcom.com...
>>  In the end, it is not a matter of whether we can code the same thing
>>  in one language that we can code in another.  It is a matter of how
>>  that same thing is expressed. It is not a matter of which syntax is
>>  more "natural"; not a matter of whether we do or do not have
>>  "distinguished receivers"; not a matter of how easy it is to code
>>  a particular set of ideas.  Expressibility, in Ada, is a matter of
>>  creating reliable, maintainable applications in which human life
>>  and safety are at risk.  For large, safety-critical software,
>>  whether that expressibility consistently represents (even demands)
>>  a model for reliability, dependability and safety.  This defines the
>>  charter for Ada.
> 
> How does Ada accomplish this? What is the language's role in ensuring
> correctness?

The role of the language is that those concerns permeate the design
of the language.  For instance, the enumerated types discussed earlier
allow me to create a variable of type Traffic_Light_Color, knowing that
the only values that can be assigned to it are Red, Yellow and Green.
Furthermore, I know it cannot mistakenly get intermixed with values
for a coworker's type Political_Orientation which has values Red
and Freedom_Loving_Capitalist.

That general idea is available in Pascal and other languages, but
Ada takes it a bit further and allows me to iterate from the start
(Traffic_Light_Color'first) to the end (Traffic_Light_Color'last)
without specifically naming the values and thus making me immune
to someone tacking on a new value at the end (or the beginning).
You can readily come up with an example where one would _not_
want to use those capabilities, but in my experience I want them
more often than not.  When the answer is "not", I don't use them.

And if it was not obvious, I have to really go out of my way to
assign the value "7" to one of those variables. If that really
is a valid traffic light color in Elbonia, then good programmers
will enhance the original declaration to make "Seven" the fourth
possiblity, thus letting the type system enforce the interface
to the outside world.

That is just a small part of the language which has safety
elements built in.  Ada is not unique in all its elements,
but it is rather thorough in safety features.

> With C's evils aside, I would guess the single largest problem for
> inexperienced C++ programmers is understanding the lifetime of objects,
> particularly temporaries used in implicit type conversions. However, the rules
> for instantiation and destruction are very simple, and are easily expressed in
> short, understandable sentences. Further, there are simple mechanisms to
> prevent implicit construction of types where this is not appropriate. The
> reason they exist, in spite of the acknowledged problems, is they are useful
> in expressing the design intent (bringing this discussion back on track). They
> are problems for inexperienced programmers, but extremely powerful when used
> appropriately.

In general, Ada tends toward compilation errors for those who have not
understood the rules.  That includes experts who have temporarily forgot
while working on something Important, as well as students whose first
reaction is to try it themselves rather than asking for their homework
answers on comp.lang.ada. :-)

Larry Kilgallen