Re: An Ada Program Does What It Says?

Re: An Ada Program Does What It Says?

[agate!spool.mu.edu!uwm.edu!caen!hellgate.utah.edu!peruvian.cs.utah.edu!ma]

In article <9301031530.AA17787@ajpo.sei.cmu.edu>, SAHARBAUGH@ROO.FIT.EDU writes
:
>I searched B&M's book and noted each example program whose 
>output is "indeterminate" or "implementation dependent".  I 
>noted the page number on which the answer appears.  

(deleted)

>My warning stands.  Ada code looks deceptively readable.  The 
>reader must understand the language translator and the 
>runtime environment to be able to correctly read an Ada 
>program.

I just finished reading those books, and yes there do seem to be a lot of
indeterminate and compiler dependent "thing" in the Ada standard.  A co-
worker and I discussed it for a while and made the observation that probably
every language has these "gotcha"'s, they just aren't as well documented
or understood.

Stuff like expression ordering, floating point representation, concurency,
etc, will always be indeterminate.

Not to trigger yet another C vs Ada flamefest, but this expression in
C is a classic example...

  r = (i++ == ++i)

-- 
Mark Atwood                  :: Being a kitten is it's own excuse.
matwood@peruvian.cs.utah.edu :: 
The University has enough problems without being blamed for mine.

Re: An Ada Program Does What It Says?

[Bjarne Stroustrup]

matwood%peruvian.cs.utah.edu@cs.utah.edu (Mark Atwood @ University of Utah) wri
tes

 > Not to trigger yet another C vs Ada flamefest, but this expression in
 > C is a classic example...
 > 
 >   r = (i++ == ++i)

Even when you point out that all languages have `gotchas' something like
this just begs for someone to jump in.

Re: An Ada Program Does What It Says?

[David Emery]

The point of Mendal & Bryan (or Bryan & Mendal, depending on volume)
is to illustrate the dark corners of the language.  As has been
pointed out, *every* language has dark corners.  (Didn't Goedel prove
this...) 

One of the big differences between the Ada "culture" and other
"cultures" is the tendency we (Ada-ites) have to make things specific.
This was clear in the POSIX business, where the Ada binding goes out
of its way to completely specify all behaviors, including
implementation-defined or undefined behaviors.  The C binding is
(deliberately) silent in many places, with the general caveat of
"anything not specified is undefined."  

Therefore it is much easier to find the implementation-defined things
in either the Ada language or POSIX/Ada, because they are explicitly
so stated.  It's a heluva lot harder to find such things when they are
not explicitly specified, such as in POSIX/C.

				dave

Re: An Ada Program Does What It Says?

[agate!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!zaphod.mps.ohio-state]

In <1993Jan4.082827.11773@hellgate.utah.edu> matwood%peruvian.cs.utah.edu@cs.ut
ah.edu (Mark Atwood) writes:

>In article <9301031530.AA17787@ajpo.sei.cmu.edu>, SAHARBAUGH@ROO.FIT.EDU write
s:
>>I searched B&M's book and noted each example program whose 
>>output is "indeterminate" or "implementation dependent".  I 
>>noted the page number on which the answer appears.  

>(deleted)

>>My warning stands.  Ada code looks deceptively readable.  The 
>>reader must understand the language translator and the 
>>runtime environment to be able to correctly read an Ada 
>>program.

>I just finished reading those books, and yes there do seem to be a lot of
>indeterminate and compiler dependent "thing" in the Ada standard.  A co-
>worker and I discussed it for a while and made the observation that probably
>every language has these "gotcha"'s, they just aren't as well documented
>or understood.

>Stuff like expression ordering, floating point representation, concurency,
>etc, will always be indeterminate.

>Not to trigger yet another C vs Ada flamefest, but this expression in
>C is a classic example...

>  r = (i++ == ++i)

It is also, of course, quite well documented and understood.  You are
correct in stating that just about every language is going to have
syntactically correct constructs which produce undefined or
implementation-defined results.  You are, however, incorrect in your
assumption that Ada is the only language in which these things are
well documented or understood.

[One typically sees a lot more people making mistakes like that above
in C simply because one sees a lot more inadequately or untrained
people working in C than one sees working in Ada -- and we're back to
the 'popularity' issue.]

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.

Re: An Ada Program Does What It Says?

[agate!spool.mu.edu!think.com!enterpoop.mit.edu!mintaka.lcs.mit.edu!ai-lab]

In article <1993Jan6.215758.10007@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com (
fred j mccall 575-3539) writes:

   >Stuff like expression ordering, floating point representation, concurency,
   >etc, will always be indeterminate.

   >Not to trigger yet another C vs Ada flamefest, but this expression in
   >C is a classic example...

   >  r = (i++ == ++i)			[*]

   It is also, of course, quite well documented and understood.  You are
   correct in stating that just about every language is going to have
   syntactically correct constructs which produce undefined or
   implementation-defined results.  You are, however, incorrect in your
   assumption that Ada is the only language in which these things are
   well documented or understood.

First, there are different degrees of undefined behavior. For example,
you could mandate that any result of expression [*] is going to
correspond to one particular order of evaluation. In particular, that
would mean that the effects of writing [*] would be limited to the
variables mentioned in the statement. I believe in the case of
order-of-evaluation dependencies, this is what C does, but for other
"undefined behavior" (notably, pointer errors), the effects are not
limited.

Language specs can make an effort to mandate features that make the
detection of bugs due to "undefined behavior" easier, for example, by
mandating compiler options that excercise the different possibilities.
Some implementations do this, but I don't know of any language
standard that even recommends it.

But more importantly, these sources of "indeterminacy" ("undefined
behavior) can be eliminated completely.  You can define order of
evaluation, you can eliminate side effects, you can mandate a
particular floating point representation, and/or you can choose models
of parallel computation that do not give rise to "indeterminacy".

I believe neither Ada nor C go far enough in this regard, although I
suspect that Ada is somewhat better than C. The only languages that I
know of that go much further in eliminating undefined behavior have
parted with the Pascal heritage (the Pascal type system, imperative
updates, processes, ...).

					Thomas.