Re: Ada Readability, Book Reference

Re: Ada Readability, Book Reference

[Alex Blakemore]

In article <9212281507.AA20416@ajpo.sei.cmu.edu> SAHARBAUGH@ROO.FIT.EDU writes:
> "Is Ada readable if you can express an indeterminate program using it?".

Any language that supports concurrency must allow indeterminate programs
to be expressed in that language.  Indeterminate order of execution of specific
 tasks
is a necessary consequence of concurrency.  The most that a language can do
is provide robust and efficient mechanisms for keeping (mostly) independent
tasks (mostly) independent - so that programmers can reason effectively about
the program's possible behavior.  Ada does this fairly well, and Ada9X is even 
better.
Ada9X also tightens the rules in several areas not involving concurrency so tha
t
program behavior is more uniformly specified (bounded) in several previous grey
 areas.

Nonetheless, IMHO you can write readable or unreadable code in any language.
Ada encourages readable software, especially with the strong division between
package interface and implementation.  Some Ada programmers actually hurt reada
bility 
by equating verbosity 100% with readability.  So a program is readable or not, 
a language
can only influence readability to a degree.  Ada excels at this, but the standa
rd that
"readability = inability to express an indeterminate program" is the wrong appr
oach.

Finally, I've recently looked at some C code that was hand translated line by l
ine
into Ada.  The C code was pretty readable and better than most - the Ada was ap
palling.
I think these are the reasons.

  1. The C standard for readability is lower.  The difference between module sp
ecs and
     implementation is much fuzzier.  Global variables are considered normal.
     So things that looked normal in C, looked appalling in Ada where I am used
     to a much more careful statement of what's an interface, what's visible et
c.

  2. The languages are different - and though some aspects of readability are
     fairly independent (use descriptive names), other idioms depend in subtle 
ways
     on the language and its culture.  Good LISP style may be bad Ada style.

  3. The human translator did not seem to know Ada well, so even when doing
     line by line translation - did not choose the best Ada constructs for doin
g
     the little things (loops instead of slice assignments for example) irregar
dless
     of being stuck with the previous decomposition into modules.

Bottom line - readability depends on many things.
-- 
---------------------------------------------------
Alex Blakemore alex@cs.umd.edu   NeXT mail accepted

Re: Ada Readability, Book Reference

[Michael Feldman]

In article <9212281507.AA20416@ajpo.sei.cmu.edu> SAHARBAUGH@ROO.FIT.EDU writes:
>I received one request for a pointer to Bryan & Mendal's
>book so I may as well post it (same amount of keystrokes).
>
[stuff deleted]
>
>For many examples the book asks, "What will this
>program print?"  For example 7.3.12 the answer is
>"The answer to the question is indeterminate."
>
>So I ask "Is Ada readable if you can express an indeterminate
>program using it?".
>
The particular example depends on the evaluation order of the sides
of the expression, but more fundamentally, speaks to the approximations
inherent in floating point. Ada's readability has little to do with it -
it's characteristic of digital computers that floating-point arithmetic
has indeterminate results sometimes, so that (A*B)/C may yield a different 
result than A*(B/C). 

In the specific case, (6.0 * 1.0)/3.0 can yield a different result from 
6.0 * (1.0 / 3.0) because 1.0/3.0 cannot be exactly represented.
Therefore an expression like
  6.0 * (1.0 / 3.0) = (6.0 * 1.0) / 3.0
may not evaluate to True. Traditional floating-point gotcha.

You chose an example that doesn't make your point very well, because a
programming language can't fix problems inherent in trying to approximate
the real numbers in a finite number of bits.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"Americans want the fruits of patience -- and they want them now."
------------------------------------------------------------------------

Re: Ada Readability, Book Reference

[Orville R. Weyrich]

In article <9212281507.AA20416@ajpo.sei.cmu.edu> SAHARBAUGH@ROO.FIT.EDU writes:
>
>So I ask "Is Ada readable if you can express an indeterminate
>program using it?".
>
>sam harbaugh
>---

I am not sure whether there is a relationship between indeterminancy and
readability.

Suppose, for example, the indeterminancy arises because of a concession made
to the implementors by way of not completely defining the effect of certain
language constructs [i.e. "implementation-defined"]. Suppose then I were to
arbitrarily define these aspects [very arbitrarily -- I'm being a devil's
advocate here] to depend on the number of comments in the compilation unit.

I have eliminated the indeterminancy, but certainly have not enhanced the
readability.

Or suppose, for another example, the indeterminancy arises because of a 
race condition that is outside the scope of control of the compiler and
run-time system. The indeterminancy could perhaps be resolved by introducing
semophores or some similar construct, but that would further complicate the
program text.

In my opinion, one of the best measure of readability is how well 
the semantics of a fragment of code can be determined in isolation from 
the context of the entire program. Another measure of readability is what
I might call "stability" -- minor changes in the code should result in
minor changes in semantics, not major changes. In other words, if a
reader has a small misunderstanding of what he/she read, and that leads
to a small misunderstanding of what the code does, the code is stable.

Happy new year to all.


orville

--------------------------------------           ******************************
Orville R. Weyrich, Jr.                           Weyrich Computer Consulting
Certified Data Processor                         POB 5782, Scottsdale, AZ 85261
Certified Systems Professional                        Voice: (602) 391-0821
Internet: orville%weyrich@uunet.uu.net                Fax:   (602) 661-0660
--------------------------------------           ******************************

Re: Ada Readability, Book Reference

[agate!spool.mu.edu!enterpoop.mit.edu!eru.mt.luth.se!lunic!sunic!nobeltech]

In article <9212281507.AA20416@ajpo.sei.cmu.edu> SAHARBAUGH@ROO.FIT.EDU writes:
>>I received one request for a pointer to Bryan & Mendal's
>>book so I may as well post it (same amount of keystrokes).
>>
>[stuff deleted]
>>
>>For many examples the book asks, "What will this
>>program print?"  For example 7.3.12 the answer is
>>"The answer to the question is indeterminate."
>>
>>So I ask "Is Ada readable if you can express an indeterminate
>>program using it?".

I think the answer should have been "The answer to the question is
compiler dependant.", and therefore: Yes, Ada is readable, although I
can express compiler dependant programs using it.

And in article <1992Dec30.035143.10291@seas.gwu.edu> mfeldman@seas.gwu.edu (Mic
hael Feldman) responded:
>The particular example depends on the evaluation order of the sides of
>the expression ... floating-point arithmetic has indeterminate results
>sometimes, so that (A*B)/C may yield a different result than A*(B/C).
>
>In the specific case, (6.0 * 1.0)/3.0 can yield a different result from 
>6.0 * (1.0 / 3.0) because 1.0/3.0 cannot be exactly represented.
>Therefore an expression like
>  6.0 * (1.0 / 3.0) = (6.0 * 1.0) / 3.0
>may not evaluate to True. Traditional floating-point gotcha.

Er... This is not a very good example. The constants used are of
universal_real type, and according to LRM 4.10(4) "... if a universal
expression is a static expression, then the evaluation must be exact."

But if I write

	B := 1.0;

	if 6.0 * (B / 3.0) = (6.0 * B) / 3.0 then

	else

	end if;

your arguments hold true.
 __  __ 
|  \   |  All opinions are my own, even if my employer claims otherwise!
|   \  |
|      |	Leif Euren			NobelTech Systems AB
|  \   |	System Manager Rational  	S-175 88 JARFALLA
|__ \__|	tel: +46-758-84072		Sweden

Re: Ada Readability, Book Reference

[Michael Feldman]

In article <1993Jan4.093155.11894@nobeltech.se> leeu@nobeltech.se (Leif Euren) 
writes:
>
[stuff deleted]
>>
>>In the specific case, (6.0 * 1.0)/3.0 can yield a different result from 
>>6.0 * (1.0 / 3.0) because 1.0/3.0 cannot be exactly represented.
>>Therefore an expression like
>>  6.0 * (1.0 / 3.0) = (6.0 * 1.0) / 3.0
>>may not evaluate to True. Traditional floating-point gotcha.
>
>Er... This is not a very good example. The constants used are of
>universal_real type, and according to LRM 4.10(4) "... if a universal
>expression is a static expression, then the evaluation must be exact."
>
>But if I write
>
>	B := 1.0;
>
>	if 6.0 * (B / 3.0) = (6.0 * B) / 3.0 then
>
>	else
>
>	end if;
>
>your arguments hold true.

Hmmm. How on earth could 1.0/3.0 be exact? What would the value be?

I checked my Annotated LRM (thanks to Karl Nyberg!) and found AI-00209:
"An implementation can refuse to evaluate a static universal real expression
only if there are insufficient resources to evaluate the expression exactly,
e.g., if there is insufficient memory available. Inexact results must not
be delivered."

This is interesting. I take it, then, that 1.0/3.0 will be flagged by
the compiler, because - unless a rational representation is being
used, which is always possible, I suppose - there aren't enough bits
in a megabyte to evaluate it exactly. Do compilers use rationals
for this?  I'll be back later, after a test or two of this!

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"Americans want the fruits of patience -- and they want them now."
------------------------------------------------------------------------

Re: Ada Readability, Book Reference

[Tucker Taft]

In article <1993Jan4.174424.5699@seas.gwu.edu> 
  mfeldman@seas.gwu.edu (Michael Feldman) writes:

>Hmmm. How on earth could 1.0/3.0 be exact? What would the value be?
>
>I checked my Annotated LRM (thanks to Karl Nyberg!) and found AI-00209:
>"An implementation can refuse to evaluate a static universal real expression
>only if there are insufficient resources to evaluate the expression exactly,
>e.g., if there is insufficient memory available. Inexact results must not
>be delivered."
>
>This is interesting. I take it, then, that 1.0/3.0 will be flagged by
>the compiler, because - unless a rational representation is being
>used, which is always possible, I suppose - there aren't enough bits
>in a megabyte to evaluate it exactly. Do compilers use rationals
>for this?  I'll be back later, after a test or two of this!

All Ada compilers I know of have "infinite precision" rational
arithmetic packages for doing static universal real expressions.
So yes, 1.0/3.0 is computed exactly in the front end of the
compiler when it is static universal.  

Most Ada compilers compute *all* static real 
expressions (even non-universal) to "infinite precision" since
that is allowed by the accuracy model and is often simpler 
than simulating the target floating-point hardware in a cross-compiler.

The infinite precision rational arithmetic package is one of 
several things that makes an Ada front end a "fun" piece
of code to write and maintain ;-).

>Mike Feldman

S. Tucker Taft   stt@inmet.com
Intermetrics, Inc.
Cambridge,  MA  02138

Re: Ada Readability, Book Reference

[Robert Firth]

In article <1993Jan4.174424.5699@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael F
eldman) writes:

>This is interesting. I take it, then, that 1.0/3.0 will be flagged by
>the compiler, because - unless a rational representation is being
>used, which is always possible, I suppose - there aren't enough bits
>in a megabyte to evaluate it exactly. Do compilers use rationals
>for this?  I'll be back later, after a test or two of this!

Mike, in my experience most Ada compilers do indeed use rational
arithmetic to represent numbers and to evaluate universal
expressions.  Together, the lexis of numbers and the syntax of
arithmetic expressions guarantee that all constructible numbers
are rational (bet you never knew one of the designers was a
closet Pythagorean!).  The number "1.0/3.0" would therefore
be held internally as 1/3, until the time came to spit out the
right bits for the chosen target machine type.

I think a universal arithmetic package is available in the Simtel
archives.

Re: Ada Readability, Book Reference

[agate!spool.mu.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!cis.ohio-state.ed]

In article <1993Jan4.174424.5699@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael F
eldman) writes:
>
>Hmmm. How on earth could 1.0/3.0 be exact? What would the value be?
>
>I checked my Annotated LRM (thanks to Karl Nyberg!) and found AI-00209:
>"An implementation can refuse to evaluate a static universal real expression
>only if there are insufficient resources to evaluate the expression exactly,
>e.g., if there is insufficient memory available. Inexact results must not
>be delivered."
>
>This is interesting. I take it, then, that 1.0/3.0 will be flagged by
>the compiler, because - unless a rational representation is being
>used, which is always possible, I suppose - there aren't enough bits
>in a megabyte to evaluate it exactly. Do compilers use rationals
>for this?  I'll be back later, after a test or two of this!
>
>Mike Feldman
>------------------------------------------------------------------------
>Michael B. Feldman
>co-chair, SIGAda Education Committee
>

About seven years ago I saw this program (I think by John Squires) on
info-ada (this is a reconstruction from memory). See how long it takes 
your compiler to give up on it -- use a batch queue if you can, especially 
on a virtual memory machine.  If it does eventually compile, you can just 
add lines until it won't...

Pat Rogers
progers@ajpo.sei.cmu.edu

-------- cut here --------

procedure Killer is

  A : constant := 1.0 / 3.0;

  B : constant := A * A * A * A * A * A * A * A * A * A * A * A * A;
  C : constant := B * B * B * B * B * B * B * B * B * B * B * B * B;
  D : constant := C * C * C * C * C * C * C * C * C * C * C * C * C;
  E : constant := D * D * D * D * D * D * D * D * D * D * D * D * D;
  F : constant := E * E * E * E * E * E * E * E * E * E * E * E * E;
  G : constant := F * F * F * F * F * F * F * F * F * F * F * F * F;
  H : constant := G * G * G * G * G * G * G * G * G * G * G * G * G;
  I : constant := H * H * H * H * H * H * H * H * H * H * H * H * H;
  J : constant := I * I * I * I * I * I * I * I * I * I * I * I * I;
  K : constant := J * J * J * J * J * J * J * J * J * J * J * J * J;
  L : constant := K * K * K * K * K * K * K * K * K * K * K * K * K;

begin
  null;
end Killer;