"Subtract C, add Ada"

"Subtract C, add Ada"

[Mitch Gart]

In the Dec. 12 PC Week, next to the review of Alsys ActivAda, 
was this sidebar by Peter Coffee:


Subtract C, add Ada: Results multiply
-------------------------------------

Few managers can afford to do a software project several times,
using teams with similar experience but different programming
tools, to see if anything yields consistent improvements in speed
or quality of work.  At the State University of New York, Plattsburgh,
though, Professor John McCormick has assigned the same project to
each of his classes for about nine years, but switched languages
in mid-decade.

Working in teams of three or four, McCormick's real-time-programming
students must write 15,000 lines of code to control a system that 
would need about 150 switches to operate using hardware alone.  In the 
five years students used C, no team completed the project - even when
more than half of the code was provided.  With Ada, however, half of
the teams completed the project before any support code had even been
written.  With some support code now provided, three out of four teams
finish the project.

Specific factors in this improvement, according to McCormick, include
both syntax and semantics.  Ada leaves less room for single-keystroke
errors, such as the common C error of using = (assignment) instead of
== (comparison); its type-abstraction facilities reduce the need for
error-prone pointer manipulation; and its modular facilities improve
teams' coordination of effort.

This experience, McCormick notes, "has convinced all my faculty
colleagues to support teaching Ada in our beginning courses.  This
spring semester, the first studentw with Ada as their mother tongue
will enroll in my course.  I can only imagine what these teams will
accomplish".

Re: "Subtract C, add Ada"

[whiting_ms@corning.com (Matt Whiting)]

In article <D1Msq8.4Hs@inmet.camb.inmet.com>, mg@asp.camb.inmet.com (Mitch Gart) writes:
> In the Dec. 12 PC Week, next to the review of Alsys ActivAda, 
> was this sidebar by Peter Coffee:
> 
> 
> Subtract C, add Ada: Results multiply
> -------------------------------------
> 
> Few managers can afford to do a software project several times,
> using teams with similar experience but different programming
> tools, to see if anything yields consistent improvements in speed
> or quality of work.  At the State University of New York, Plattsburgh,
> though, Professor John McCormick has assigned the same project to
> each of his classes for about nine years, but switched languages
> in mid-decade.
>  . 
>  . 
>  . 
-- 

I read the PC Week article, but found no contact information for professor
McCormick.  I searched via InterNIC and found a listing for a John McCormick,
but it gave only a telephone number and didn't indicate a location or an email
address.  Does anyone know professor McCormick and know if he has an email
address?  I can call the McCormick listed, but I'd like to have some idea if
this is the right person beforehand.

-------------------------------------------------------------------------------
Matthew S. Whiting, P.E. | Corning Incorporated  | (607) 974-6317 phone
Sr. Project Engineer     | HP-ME-03-073          | (607) 974-6752 fax
whiting_ms@corning.com   | Corning, NY 14831     |

Re: "Subtract C, add Ada"

[Fred McCall]

In <D1Msq8.4Hs@inmet.camb.inmet.com> mg@asp.camb.inmet.com Mitch Gart writes:

>Ada leaves less room for single-keystroke
>errors, such as the common C error of using = (assignment) instead of
>== (comparison); 

I've always been curious.  Just *where* is this a "common C error"?
I've seen lots of beginners and non-C programmers claim it is, but I
don't recall ever hearing of anyone who knew what they were doing (and
who was using a real tool -- say, lint -- to check their code) making
it. 

>its type-abstraction facilities reduce the need for
>error-prone pointer manipulation; 

Afraid this one doesn't seem to make sense.  How does being able to
define a dozen incompatible types of integer "reduce the need for
error-prone pointer manipulation"?  

>and its modular facilities improve
>teams' coordination of effort.

Both languages are modular.  I'm not sure how this is a 'win' unless
we're talking about totally inexperienced teams.

>
>This experience, McCormick notes, "has convinced all my faculty
>colleagues to support teaching Ada in our beginning courses.  This
>spring semester, the first studentw with Ada as their mother tongue
>will enroll in my course.  I can only imagine what these teams will
>accomplish".

Well, Ada is certainly a better choice than C for a beginning language
to teach design concepts, etc. However, that isn't necessarily saying a
whole lot, since that wasn't what C was intended for. I'm also not sure
why that would be considered a 'plus', unless the idea behind Ada was to
come up with a good language for beginners; that wasn't the idea behind
it.


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

Re: "Subtract C, add Ada"

[Jay M. Martin]

Mitch Gart (mg@asp.camb.inmet.com) wrote:

About a Professor John McCormick who did some language efficiency
studies Ada vs C.



Why doesn't he publish his results?  Such data points need to be
collected in journals even though they may not be overwhelming 
evidence by themselves.  With enough data points "facts" about
the efficiency of different methods of software development can
be derived.  Unfortunately, I have never seen the Computer Science
community do this .  Jay

Re: "Subtract C, add Ada"

[Richard Pattis]

In article <862035D1F1C@annwfn.com> merlin@annwfn.com (Fred McCall) writes:
>In <D1Msq8.4Hs@inmet.camb.inmet.com> mg@asp.camb.inmet.com Mitch Gart writes:
>
>>Ada leaves less room for single-keystroke
>>errors, such as the common C error of using = (assignment) instead of
>>== (comparison); 
>
>I've always been curious.  Just *where* is this a "common C error"?
>I've seen lots of beginners and non-C programmers claim it is, but I
>don't recall ever hearing of anyone who knew what they were doing (and
>who was using a real tool -- say, lint -- to check their code) making
>it. 

In Peter van der Linden's excellent book, "Expert C Programming: Deep C
Secrets", Prentice Hall, on page xx (that's 20 in the preface) he describes
a problem from 1993 in the Operating System development group at SunSoft
(he works at Sun and was part of the debugging effort he describes). A bug
in the asynchronous I/O libary was holding up a $20million dollar sale - the
customer needed the library to work. It turns out that someone had written
x==2 by accident. As van der Linden states

"Some versions of the lint program would have detected this problem, but it's
all too easy to avoid the automatic use of this essential tool."

Rich
-- 
------------------------------------------------------------------------------
  Richard E. Pattis                     "Programming languages are like
  Looking for a Job                      pizzas - they come in only "too"
					 size: too big and too small.

Re: "Subtract C, add Ada"

[Michael Feldman]

In article <1995Jan3.140431.1@corning.com>,
whiting_ms@corning.com (Matt Whiting) <whiting_ms@corning.com> wrote:

>I read the PC Week article, but found no contact information for professor
>McCormick.  I searched via InterNIC and found a listing for a John McCormick,
>but it gave only a telephone number and didn't indicate a location or an email
>address.  Does anyone know professor McCormick and know if he has an email
>address?  I can call the McCormick listed, but I'd like to have some idea if
>this is the right person beforehand.

John's address is MCCORMJW@splava.cc.plattsburgh.edu.

A TRI-Ada '91 paper on this project at Plattsburgh won the Best Paper 
award at that conference. What the PC Week story left out is that the
real-time system they build in that course controls an HO train setup.
It's a really nice piece of work.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
------------------------------------------------------------------------
One, two, three ways an underdog: Ada fan, Mac fan, Old Liberal Democrat
------------------------------------------------------------------------
         Ada on the World-Wide Web: http://lglwww.epfl.ch/Ada/
------------------------------------------------------------------------

Re: "Subtract C, add Ada"

[Michael Feldman]

In article <D1wKJn.HAu@seas.ucla.edu>,
Jay M. Martin <jaym@breeze.seas.ucla.edu> wrote:
>
>Why doesn't he publish his results?  Such data points need to be
>collected in journals even though they may not be overwhelming 
>evidence by themselves.  With enough data points "facts" about
>the efficiency of different methods of software development can
>be derived.  Unfortunately, I have never seen the Computer Science
>community do this .  Jay

Actually, he published it twice. One paper was in TRI-Ada '91, which
got the Best Paper award in that conference; the other was in Communications
of the ACM, in the Ada section of the November 1992 issue.

You really ought to check your facts before making these generalizations.
Maybe _ask_ first whether John published anything on this. He's also
discussed it in numerous panels in both SIGCSE and SIGAda circles.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
------------------------------------------------------------------------
One, two, three ways an underdog: Ada fan, Mac fan, Old Liberal Democrat
------------------------------------------------------------------------
         Ada on the World-Wide Web: http://lglwww.epfl.ch/Ada/
------------------------------------------------------------------------

Re: "Subtract C, add Ada"

[Kevin Weise]

In article <862035D1F1C@annwfn.com>, Fred McCall <merlin@annwfn.com> wrote:
>In <D1Msq8.4Hs@inmet.camb.inmet.com> mg@asp.camb.inmet.com Mitch Gart writes:
>
>>Ada leaves less room for single-keystroke
>>errors, such as the common C error of using = (assignment) instead of
>>== (comparison); 
>
>I've always been curious.  Just *where* is this a "common C error"?
>I've seen lots of beginners and non-C programmers claim it is, but I
>don't recall ever hearing of anyone who knew what they were doing (and
>who was using a real tool -- say, lint -- to check their code) making
>it. 

Well, Mr. McCall, I will attempt to respond to this in a fashion that
does not violate netiquette.  However, from previous threads here on
CLA, I believe this is one of your hot buttons.  The fact is, I know
lots of C/C++ people, and quite a few of them agree that this is a
common error they make {e.g., if (var = expr), rather than 
if (var == expr)}.  These people are not beginners; but some of them are
certainly hackers.  Nonetheless, as far as I've seen, this is a
well-known recognized source of common errors.  Certainly a good lint
program will question this usage; that's not at issue.  But I believe
that = vs. == was used as an example of single character errors that
make it through the compiler; certainly it is not the only one.  

>
>>its type-abstraction facilities reduce the need for
>>error-prone pointer manipulation; 
>
>Afraid this one doesn't seem to make sense.  How does being able to
>define a dozen incompatible types of integer "reduce the need for
>error-prone pointer manipulation"?  

While I agree with you that the introduction of multiple scalar types
in Ada programs can be abused, I don't think that is what was being 
referred to.  Two examples that come to my mind are the common practice 
of equating ints with pointers (although thankfully this is becoming
less  common these days) and the practice of passing non-scalar data by 
reference with the concommitant possible type mismatch between 
subprograms.  Thus, there is a point of view that makes sense.

>
>>and its modular facilities improve
>>teams' coordination of effort.
>
>Both languages are modular.  I'm not sure how this is a 'win' unless
>we're talking about totally inexperienced teams.
>
Agreed, both languages are modular.  But I think that the author may
have meant that strong typing is too easily circumvented in C; this
degrades coordination between teams.  This is not to say that
circumventing strong typing is unnecessary; I agree that it is
necessary sometimes.  I just prefer being better able to recognize when
its being done in code that I'm reading.

>>
>>This experience, McCormick notes, "has convinced all my faculty
>>colleagues to support teaching Ada in our beginning courses.  This
>>spring semester, the first studentw with Ada as their mother tongue
>>will enroll in my course.  I can only imagine what these teams will
>>accomplish".
>
>Well, Ada is certainly a better choice than C for a beginning language
>to teach design concepts, etc. However, that isn't necessarily saying a
>whole lot, since that wasn't what C was intended for. I'm also not sure
>why that would be considered a 'plus', unless the idea behind Ada was to
>come up with a good language for beginners; that wasn't the idea behind
>it.

Well, I think it says alot.  There's a belief that the way we think
about problem solving is directly related to the language(s) we know.
This is because language provides structure to the concepts and ideas we
use for thinking.  (This belief did not come out of computer science or
engineering, either.)  It only makes sense that a programming language
that provides good direct support for design issues as well should be of
great benefit.  Projects that I've seen that used Ada & failed did so
for a variety of reasons; but a frequent one was that it was designed with
a (FORTRAN, asembly, whatever) mindset but coded in Ada.  It shouldn't
take a rocket scientist to figure out that the effect is the same if you
do a literal translation from any other natural language into English.

However, for me, what really said a lot is that *none* of the teams that
used C finished the project, whereas one half to three fourths of the
teams that used Ada did.  Undoubtedly, you are a good software developer
and/or maintainer (even designer!); but perhaps there's more to the
assertions about language problems with C than you are willing to
accept.

----------------------------------------------------------------
Kevin J. Weise			weisek@source.asset.com
COLSA Corporation		Voice - (205) 922-1512 ext. 2115
6726 Odyssey Drive		FAX   - (205) 971-0002
Huntsville, AL  35806
{Standard Disclaimers about my opinions & my employer's opinions}
{... which are in conflict often enough}
----------------------------------------------------------------
"Admire those who seek the truth;
  avoid those who find it."		Marcel Proust

Re: "Subtract C, add Ada"

[Jay Martin]

mfeldman@seas.gwu.edu (Michael Feldman) writes:

>In article <D1wKJn.HAu@seas.ucla.edu>,
>Jay M. Martin <jaym@breeze.seas.ucla.edu> wrote:
>>
>>Why doesn't he publish his results?  Such data points need to be
>>collected in journals even though they may not be overwhelming 
>>evidence by themselves.  With enough data points "facts" about
>>the efficiency of different methods of software development can
>>be derived.  Unfortunately, I have never seen the Computer Science
>>community do this .  Jay

>Actually, he published it twice. One paper was in TRI-Ada '91, which
>got the Best Paper award in that conference; the other was in Communications
>of the ACM, in the Ada section of the November 1992 issue.

>You really ought to check your facts before making these generalizations.
>Maybe _ask_ first whether John published anything on this. He's also
>discussed it in numerous panels in both SIGCSE and SIGAda circles.

>Mike Feldman

I read the abstracts to these papers before I posted, there is not
one peep about the relative efficiency between C and Ada which
should be the central topic of discussion in my opinion.
Here are the abs:
1. CONFERENCE PAPER
   McCormick, J.W.
     Using a model railroad to teach Ada and software engineering.
   IN:  TRI-Ada '91 Proceedings. (TRI-Ada '91 Proceedings, San Jose, CA, USA,
   21-25 Oct. 1991). New York, NY, USA: ACM, 1991. p. 511-14.
     Pub type:  Practical.

Abstract: This paper describes a successful course for teaching the development
     of Ada software systems. A computer controlled model railroad provides
     realistic small problems that give students experience with Ada's unique
     aspects and larger problems that require software engineering skills.

3. McCormick, J.W.
     A model railroad for Ada and software engineering.
   Communications of the ACM, Nov. 1992, vol.35, (no.11):68-70.
     Pub type:  Practical.

Abstract: The Computer Science Department at SUNY Plattsburgh has developed a
     study option in computer controlled systems. This study option was created
     especially for undergraduate students interested in the engineering of
     embedded and real-time software systems. Besides the core courses required
     in all study options, students in the computer controlled systems study
     option takes courses in physics (including electronics), additional
     courses in continuous mathematics and a selection of upper division
     computer science courses. The capstone course in the computer controlled
     systems option is real-time systems. As part of the real-time systems
     course, students work in teams to develop Ada software to control a model
     railroad. The computer-controlled model railroad is a successful tool for
     teaching the development of Ada software systems to undergraduate
     students. Because of their interest in writing software to control trains,
     students are highly motivated to learn Ada. The railroad is an excellent
     platform for demonstrating Ada's capabilities. In particular, Ada's
     tasking, exception handling and hardware-dependent features are utilized
     frequently by students writing railroad control software.

5. CONFERENCE PAPER
   McCormick, J.W.
     A laboratory for teaching the development of real-time software systems.
     (22nd SIGCSE Technical Symposium on Computer Science Education, San
     Antonio, TX, USA, 7-8 March 1991).
   SIGCSE Bulletin, March 1991, vol.23, (no.1):260-4.
     Pub type:  Practical.

Abstract: A major problem with teaching real-time software development to
     undergraduate students is finding suitable equipment for assignments and
     projects. Such equipment must provide problems that are exciting,
     challenging, cover a broad range of real-time topics, and yet have
     solutions that can be completed within the time constraints of the
     semester. The paper describes a successful laboratory for an undergraduate
     course in real-time software development based on a computer controlled
     model railroad.


Where is C sucks! Ada rules!   I reiterate, I have never seen (recent)
a study done by Computer Science Researchers on the relative efficiency
of software tools.  Jay

Re: "Subtract C, add Ada"

[Robert Dewar]

"Where is C sucks, Ada rules"

I'll tell you where, in inappropriate posts to comp.lang.ada, that's where!
John's papres are excellently presented, and I think giving them more of a
langauge wars slant would be a big mistake. Yes, if you read the papers
you will get an important message if you are not deaf, but the critical
issue here is not simple us vs them language comparisons.

Re: "Subtract C, add Ada"

[Michael M. Bishop]

In article <3ehcik$lc0@oahu.cs.ucla.edu>,
Jay Martin <jmartin@oahu.cs.ucla.edu> wrote:
>mfeldman@seas.gwu.edu (Michael Feldman) writes:
>
>>In article <D1wKJn.HAu@seas.ucla.edu>,
>>Jay M. Martin <jaym@breeze.seas.ucla.edu> wrote:
>>>[snip]
>
>>Actually, he published it twice. One paper was in TRI-Ada '91, which
>>got the Best Paper award in that conference; the other was in Communications
>>of the ACM, in the Ada section of the November 1992 issue.
>
>>You really ought to check your facts before making these generalizations.
>>Maybe _ask_ first whether John published anything on this. He's also
>>discussed it in numerous panels in both SIGCSE and SIGAda circles.
>
>>Mike Feldman
>
>I read the abstracts to these papers before I posted, there is not
>one peep about the relative efficiency between C and Ada which
>should be the central topic of discussion in my opinion.
[snip]

Why should the relative efficiency between C and Ada be a central topic
of discussion? (I assume you mean run-time efficiency.) With today's
advanced hardware and improved code-generation techniques, run-time
efficiency is, IMHO, an overrated issue. If this was a pertinent issue,
there should be numerous examples of how using Ada caused a development
team to fail to meet real-time requirements. I haven't see any. (Perhaps
the perception that Ada compilers don't generate efficient code scares
developers away from using Ada for real-time applications.)

The topic of discussion in this thread is that the use of Ada enabled
more of John's students to complete their assignments than the use of
C did. That should be the central topic of discussion. If software can't
be delivered on time or delivered at all, efficiency is the least of the
problems. 

Having developed Motif applications in both C and Ada, I can honestly
say that I've noticed no differences in run-time efficiency between the
two languages. (And this is without removing the run-time checks from
the Ada system.) Having said this, I must add that I haven't gathered
any statistics to support the above claim. But then, I've got better
things to do than collecting run-time statistics.
-- 
| Mike Bishop              | The opinions expressed here reflect    |
| bishopm@source.asset.com | those of this station, its management, |
| Member: Team Ada         | and the entire world.                  |

Re: "Subtract C, add Ada"

[Jahn Rentmeister]

Fred McCall (merlin@annwfn.com) wrote:
: In <D1Msq8.4Hs@inmet.camb.inmet.com> mg@asp.camb.inmet.com Mitch Gart writes:

: >Ada leaves less room for single-keystroke
: >errors, such as the common C error of using = (assignment) instead of
: >== (comparison); 

: I've always been curious.  Just *where* is this a "common C error"?
: I've seen lots of beginners and non-C programmers claim it is, but I
: don't recall ever hearing of anyone who knew what they were doing (and
: who was using a real tool -- say, lint -- to check their code) making
: it. 

But you surely know about people who - at one time - wrote things like

   for (i=0; i < MAX_LOOP; i++);
      field[i]=GetFieldValue(i);

The original statement you were criticizing says "single-keystroke errors,
such as...". There are more of them than just assignment and empty loops.
My golden C rule says "any sufficiently obscure error is due to a missing or
superfluos semicolon".

: >its type-abstraction facilities reduce the need for
: >error-prone pointer manipulation; 

: Afraid this one doesn't seem to make sense.  How does being able to
: define a dozen incompatible types of integer "reduce the need for
: error-prone pointer manipulation"?  

Afraid your answer doesn't seem to make sense.
Read it again: He is talking about type-abstraction, i.e. abstract Data
Types such as bags, stacks, linked lists, Bayer-Trees etc.
In C, people do this using void pointers - this means no type checking at
all. Even lint can't check anything there. This _is_ error-prone.

In Ada, you may encapsulate a pointer (or whatever) into a limited private
type, only allowing very few things to be done with the
pointer/file/whatever. In C, this is not possible. (We're not talking about
C++ right now.)

: >and its modular facilities improve
: >teams' coordination of effort.

: Both languages are modular.  I'm not sure how this is a 'win' unless
: we're talking about totally inexperienced teams.

We are talking about totally inexperienced teams here.
And - again - read carefully: "Modular facilities", not "modularity" as
such. The statement is that Ada provides some modular facilities that C does
not provide, not that C isn't modular. Just two examples:

In Ada, you can't use an obsolete package, because the compiler knows from
the library it's obsolete. In C, it can become quite tricky to ensure this
via make. Of course, you can do it, but you can't force people to use make
neither to only produce correct makefiles.

Private and limited private types are a "modular facility", too. With them,
you know you don't rely upon internals of a module, because you know you
can't even access them.

: Well, Ada is certainly a better choice than C for a beginning language
: to teach design concepts, etc. However, that isn't necessarily saying a
: whole lot, since that wasn't what C was intended for. 

No one claimed that it is saying a lot. The statement was "look, Ada makes
a success of a course where C failed. Let us teach Ada in beginning
courses." 

: I'm also not sure
: why that would be considered a 'plus', 

I'm sure it is a 'plus' for the students, for the teachers and for the
university. Well-trained personnel is a 'plus' for the companies that hire
them. That's why.

: unless the idea behind Ada was to
: come up with a good language for beginners; that wasn't the idea behind
: it.

The idea behind Ada was to come up with a perfect language, which did not
at all work. (Nevertheless, it's the best try I've seen so far.)

-Jahn
--
## PsionCrosspoint 3a Series V 0.99 B ##

Re: "Subtract C, add Ada"

[Laurent Gasser]

I am a happy user of Think Pascal for Macintosh.  This defunct
compiler had two great (innovative?) tools: its debugger and an 
automatic text formatter in the editor.  You just type

if mytest then begin end else begin end;

and at the ; the automatic formatter gives

IF mytest THEN BEGIN
END
ELSE BEGIN
END;
  
where capitals may be bold (this is somehow parametable).  This avoids 
many many typos (in which case the formatter scrambles the mistyped 
word) and makes it easy to move up or down with respect to nesting. 
All this is done without compiling.  Surprisingly, this feature has 
not caught on in other environments I know... !?

Is this part of GNAT?

In article <3ejf9b$hbg@majestix.uni-muenster.de>, rentmei@asterix.uni-muenster.de (Jahn Rentmeister) writes:
|> But you surely know about people who - at one time - wrote things like
|> 
|>    for (i=0; i < MAX_LOOP; i++);
|>       field[i]=GetFieldValue(i);
|> 
|> The original statement you were criticizing says "single-keystroke errors,
|> such as...". There are more of them than just assignment and empty loops.
|> My golden C rule says "any sufficiently obscure error is due to a missing or
|> superfluos semicolon".

-- 
Laurent Gasser (gasser@dma.epfl.ch)
Computers do not solve problems, they execute solutions.

I know very few ideas worth dying for, none is worth killing.

Re: "Subtract C, add Ada"

[David Weller]

In article <3ejs70$dd8@info.epfl.ch>,
Laurent Gasser <gasser@masg1.epfl.ch> wrote:
>I am a happy user of Think Pascal for Macintosh.  This defunct
>compiler had two great (innovative?) tools: its debugger and an 
>automatic text formatter in the editor.  You just type
>
>if mytest then begin end else begin end;
>and at the ; the automatic formatter gives
>
>[example deleted]

>where capitals may be bold (this is somehow parametable).  This avoids 
>many many typos (in which case the formatter scrambles the mistyped 
>word) and makes it easy to move up or down with respect to nesting. 
>All this is done without compiling.  Surprisingly, this feature has 
>not caught on in other environments I know... !?
>
>Is this part of GNAT?
>
Not at all.  GNAT is a compiler, not an environment.  To get such a
behavior, you will need to use the GNU Emacs editor/environment and
get the Ada-mode additions from cs.nyu.edu.  It will do something
very much like you're looking for (much more, to be honest).

There are other editors out there that will support this mode, but
none that I know of (currently) work with GNAT or Ada95.

>In article <3ejf9b$hbg@majestix.uni-muenster.de>, rentmei@asterix.uni-muenster.de (Jahn Rentmeister) writes:
>|> But you surely know about people who - at one time - wrote things like
>|> 
>|>    for (i=0; i < MAX_LOOP; i++);
>|>       field[i]=GetFieldValue(i);
>|> 
>|> The original statement you were criticizing says "single-keystroke errors,
>|> such as...". There are more of them than just assignment and empty loops.
>|> My golden C rule says "any sufficiently obscure error is due to a missing or
>|> superfluos semicolon".
>
>-- 
>Laurent Gasser (gasser@dma.epfl.ch)
>Computers do not solve problems, they execute solutions.
>
>I know very few ideas worth dying for, none is worth killing.


-- 
       Frustrated with C/C++, Pascal, Fortran?  Ada95 _might_ be for you!
	  For all sorts of interesting Ada95 tidbits, run the command:
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
	

Re: "Subtract C, add Ada"

[David Weller]

SOrry about not trimming down my reply -- I'm trying to answer all
this stuff doring my (almost over) lunch break.

-- 
       Frustrated with C/C++, Pascal, Fortran?  Ada95 _might_ be for you!
	  For all sorts of interesting Ada95 tidbits, run the command:
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
	

Re: "Subtract C, add Ada"

[Kenneth Almquist]

In article <862035D1F1C@annwfn.com>, Fred McCall <merlin@annwfn.com> wrote:
> In <D1Msq8.4Hs@inmet.camb.inmet.com> mg@asp.camb.inmet.com Mitch Gart writes:
>
>> Ada leaves less room for single-keystroke
>> errors, such as the common C error of using = (assignment) instead of
>> == (comparison); 
>
> I've always been curious.  Just *where* is this a "common C error"?
> I've seen lots of beginners and non-C programmers claim it is, but I
> don't recall ever hearing of anyone who knew what they were doing (and
> who was using a real tool -- say, lint -- to check their code) making
> it. 

I confuse "=" and "==" periodically even though I've used C for years.

I generally don't use lint.  I just ran this "real tool" on the program:

   #include <stdio.h>
   #include <stdlib.h>

   main(int argc, char **argv) {
       printf("hello, world\n");
       exit(0);
   }

The result is four useless messages:

   hello.c(4): syntax error at or near type word "int"
   hello.c(7): warning: main() returns random value to invocation environment
   exit value declared inconsistently	llib-lc(236)  ::  hello.c(6)
   printf returns value which is always ignored

>> its type-abstraction facilities reduce the need for
>> error-prone pointer manipulation; 
>
> Afraid this one doesn't seem to make sense.  How does being able to
> define a dozen incompatible types of integer "reduce the need for
> error-prone pointer manipulation"?  

I'm not sure what was intended here either.  Ada has generic packages
and procedures, which makes it easier to write type-safe library routines
which manipulate pointers.

>> and its modular facilities improve
>> teams' coordination of effort.
>
> Both languages are modular.  I'm not sure how this is a 'win' unless
> we're talking about totally inexperienced teams.

I took a software engineering course in which included a group project.
The group I was in defined all of the interfaces in Modula 2.  Some of
the code was written in C because nobody on the project knew Modula 2
well, but I don't think we would have had a chance of completing the
project in the ten weeks allotted if we hadn't used Modula 2 for the
interfaces.

>> This experience, McCormick notes, "has convinced all my faculty
>> colleagues to support teaching Ada in our beginning courses.  This
>> spring semester, the first student with Ada as their mother tongue
>> will enroll in my course.  I can only imagine what these teams will
>> accomplish".
>
> Well, Ada is certainly a better choice than C for a beginning language
> to teach design concepts, etc. However, that isn't necessarily saying a
> whole lot, since that wasn't what C was intended for. I'm also not sure
> why that would be considered a 'plus', unless the idea behind Ada was to
> come up with a good language for beginners; that wasn't the idea behind
> it.

C was intended for (or at least the early feedback on its design came
from) programmers writing individual programs.  In contrast, Ada was
explicitly designed to support multi-person projects.  It is nice to
see that the relative usefulness of these languages for group projects
reflects the intentions of the language designers.
				Kenneth Almquist

Re: "Subtract C, add Ada"

[Jay Martin]

>From: dewar@cs.nyu.edu (Robert Dewar)

>>"Where is C sucks, Ada rules"

>I'll tell you where, in inappropriate posts to comp.lang.ada, that's where!
>John's papres are excellently presented, and I think giving them more of a
>langauge wars slant would be a big mistake. Yes, if you read the papers
>you will get an important message if you are not deaf, but the critical
>issue here is not simple us vs them language comparisons.

To start I'll quote from an paper abstract that I included below:

  The selection of a convenient programming language is one of the most
  important decisions to be made prior to the implementation of any software
  project and it may greatly affect its development and maintenance costs.


I am just a crackpot, but I think it is reasonable that some people
somewhere on this planet should be studying the efficiency of
software construction, programming language design and the
interaction between the two.  Unfortunately, I don't see anybody
doing it.  Industry doesn't have the time (I can just see efficiency
studies from Microsoft saying MSDOS is 100X easier to learn than the
Mac) which leaves academia.  But from what I have seen Computer
Science has declared the field "not worthy of study" and there is no
other academic field that can do the work (There doesn't seem that
very many Software Engineering departments around).  I believe that
this is because of some vain effort at scientifization of the field
(Physics Envy).  Language comparisons involve heated debate and
instead of putting up with chaos the Computer Science field has just
punted on the whole subject. "Can't we all just get along?", "We will
just agree to disagree" and other efforts to sweep these important
issues under a rug has made Computer Science pretty
worthless/spine-less. Computer Scientists seem to have declared
programming,etc as trivial and not worthy of their concern.  How can
we expect them to be motivated to learn about and then teach the
latest in programming, language understanding and design.  Its really
not their field, why should they give a rats ass.  The legions of
incompetent college graduage programmers are the result.  Who will
answer the "The Fundamental Question of Computer Science":  "Which
tool/language should I use?".


Maybe Computer Science should just stop teaching programming since it
really doesn't have much do with the field.  Maybe Computer Science
needs to be destroyed, yeah we can shove architecture into
EE/Computer Engineering,  Theory/Algorithms/Analysis into Applied
Math/Operations Research, AI into Cignus-X1 (a black hole) (no loss),
Networking into a new telecommunications field, Databases into
Novell(etc).  Since no one studies software systems/programming
languages, the destruction of CS is complete.

More constructively, maybe all Computer Science professors should be
required to be certified Software Engineers participating in
continuing education seminars and the requirement to have be part of
a non-trivial software projects that uses state of the art software
techniques every few years (with their programming reviewed). 

>John's papres are excellently presented, and I think giving them more of a
>langauge wars slant would be a big mistake. Yes, if you read the papers
>you will get an important message if you are not deaf, but the critical
>issue here is not simple us vs them language comparisons.

Going back to my point. No one is spending any effort doing reasonable
language comparison studies, thus all discussions comparing
languages/tools are called "religious", "inappropriate", "language
wars".  "Language comparisons are religions due to the absence of
studies, thus doing studies on language comparison is religious"
(circular logic). I understand why Prof McCormick can't be too
aggressive in declaring Ada the winner over C in a study or make
language comparison the centerstone of a paper.  The Computer Science
community and others will stone him to death for blaspheme.  I am
just saddened that one of the few people on the planet that may have
language comparison data can't make it widely available in a highly
visable way. 

I leave you with the abstracts to all the recent articles on language
comparisons I could find by searching a reference database:

Jay


--------------------------------------------------------------------
-- Wiener, R.
      Comparing OOP languages.
    IN:  Object EXPO Europe Conference Proceedings. (Object EXPO Europe
    Conference Proceedings, London, UK, 12-16 July 1993). New York, NY, USA:
    SIGS Publications, 1993. p. 7-8.
      Pub type:  Practical.

Abstract: Summary form only given. The author critically examines and compares
     significant features of C++, Smalltalk, and Eiffel. There are three broad
     areas that are used as the basis for comparison: software development
     issues, technical issues, and performance issues. Under software
     development issues, a comparison is made regarding how easy it is to map
     object-oriented design to each language. Under technical issues, each
     language is compared with respect to static versus dynamic type checking,
     early versus late binding, and support for generic classes. Under
     performance issues, each language is compared in terms of size and speed
     for some typical code and compilation speed, if appropriate.

-- Cullyer, W.J.; Wickmann, B.A.
       The choice of computer languages for use in safety-critical systems.
     Software Engineering Journal, March 1991, vol.6, (no.2):51-8.
       Pub type:  Practical.

Abstract: The paper reviews the choice of computer language for use in
     safety-critical systems. The advice given reflects both civil and military
     requirements. A comparison is made between assembly-level languages, the
     language C, CORAL 66, Pascal, Modula-2 and Ada. It is concluded that a
     well defined sub-language is essential for use in safety-critical
     projects, and a guide is provided for project managers and designers on
     the characteristics which such a subset should possess.

-- Plauger, P.J.
      Programming language guessing games.
    Dr. Dobb's Journal, Oct. 1993, vol.18, (no.11):16-22.
      Pub type:  General or Review.

Abstract: For all its promise, C++ is, unequivocally, a complex language-and
     history has not been kind to complex programming languages. Three that
     spring to mind are PL/I, Algol 68, and Ada. Each is a product of a
     different decade and a different (potential) user community, but each has
     followed a similar trajectory. So where does that leave C++? If it's
     following the inevitable fate of complex languages, then it's arguably
     still in the 'rising tide' stage. We can trust that its popularity and
     importance are both still growing. But we can also trust that it will not
     be the programming language of choice in the year 2000.

-- Floyd, M.
      Comparing object-oriented languages.
    Dr. Dobb's Journal, Oct. 1993, vol.18, (no.11):104-18.
      Pub type:  Practical.

Abstract: In this article, a number of programmers were invited to implement a
     simple linked-list class in their favorite objected-oriented language. The
     linked-list was chosen because it's widely used and understood, making it
     easier to compare how different languages approach a given problem. This,
     in effect, allows the code to speak for itself. To this end, one can
     examine and compare approaches in C++, Smalltalk, Eiffel, Sather,
     Objective-C, Parasol, Beta, Turbo Pascal, C+@, Liana, Ada, and Drool.


-- Wild, F.H., III.
      A comparison of experiences with the maintenance of object-oriented
    systems: Ada vs. C++.
    IN:  Proceedings TRI-Ada '90. (Proceedings TRI-Ada '90, Baltimore, MD, USA,
    3-7 Dec. 1990). New York, NY, USA: ACM, 1990. p. 66-73.
      Pub type:  Practical.

Abstract: A discussion is given on the relative ease with which systems are
     maintained using the mechanisms supported by Ada versus those supported by
     C++. The author opens with a discussion of significant aspects of
     object-oriented development, followed by comments about relevant support
     mechanisms supplied by each language. Qualitative comments are used freely
     regarding issues of object inter-relationship complexities, object
     construction and reuse paradigms, readability aspects, and others.

-- Overview of US Air Force report 'Ada and C++: a business case analysis'.
    Ada Information Clearinghouse Newsletter, Sept. 1991, vol.9, (no.3):22-6.
      Pub type:  Practical.

Abstract: On July 9, 1991, the US Air Force released to the public a report of
     a business-case study they had conducted to determine under what
     circumstances a waiver to DoD's Ada requirement might be warranted in
     order to allow the use of C++, particularly in DoD's corporate information
     management (CIM) program. The report is titled, 'Ada and C++: A Business
     Case Analysis.' An overview is given of the study.

-- Campbell, R.A.; Jones, S.; Cottle, R.
       A comparison of object oriented simulation languages.
     IN:  Cooperation. 1990 ACM Eighteenth Annual Computer Science Conference
     Proceedings. (Cooperation. 1990 ACM Eighteenth Annual Computer Science
     Conference Proceedings, Washington, DC, USA, 20-22 Feb. 1990). New York,
     NY, USA: ACM, 1990. p. 412.
       Pub type:  Practical.

Abstract: A network computer system was simulated as a single server queuing
     system using several computer languages including two object oriented
     languages. An initial simulation using Smalltalk-V was implemented on a
     Macintosh II microcomputer. A procedure oriented Pascal program was then
     implemented on the Mac II machine. A HP Vectra PC was then used to
     implement the same problem in Pascal, with and without an object oriented
     option on Turbo Pascal 5.5. The programming was performed by two
     undergraduate computer science students with considerable programming
     experience, but who were using object oriented concepts for the first
     time. Both students found that using an object oriented system in a
     programming environment supplied by Smalltalk V was a little different
     than programming in a procedure oriented language such as Pascal. Once
     they became familiar with the Smalltalk environment, they both felt that
     they would prefer to develop simulation systems in Smalltalk.

-- Yatim, D.; Sygenda, S.A.
       Performance comparison between C and Modula-2 in the context of gate
     level, table driven concurrent fault simulation.
     IN:  Proceedings of the 1990 Summer Computer Simulation Conference.
     (Proceedings of the 1990 Summer Computer Simulation Conference, Calgary,
     Alta., Canada, 16-18 July 1990). Edited by: Svrcek, B.; McRae, J. San
     Diego, CA, USA: SCS, 1990. p. 116-22.
       Pub type:  Practical.

Abstract: The selection of a convenient programming language is one of the most
     important decisions to be made prior to the implementation of any software
     project and it may greatly affect its development and maintenance costs.
     The authors compare two popular general-purpose programming languages, C
     and Modula-2, in the context of: gate level, table driven, concurrent
     fault simulation in a time sharing multi-user environment. Both static and
     dynamic software metrics are considered.

-- English, J.
      Object-oriented programming and Ada 9X: what can we learn from C++?.
    IN:  ADA: towards maturity. Edited by: Collingbourne, L. Amsterdam,
    Netherlands: IOS Press, 1993. p. 71-94.
      Pub type:  Practical.

Abstract: One of the most important new features proposed for Ada 9X is the
     inclusion of support for object-oriented programming. C++ is a descendant
     of C which supports object-oriented programming and which is now
     established as one of the major object-oriented languages. Like Ada 9X,
     C++ is a development of an existing procedural language which imposes the
     need for it to provide backward compatibility. Unlike Ada 9X, C++ has been
     available now for a number of years and a great deal of experience of its
     usefulness in practice has been acquired. This paper presents a comparison
     of the features of Ada 9X and C++ which are intended to support
     object-oriented programming. It examines the object-oriented features of
     C++ and considers whether the features proposed for Ada 9X can provide the
     expressive power of C++ while at the same time avoiding the complexities
     arising from C++'s incremental evolution. In addition, it describes some
     of the problems encountered with C++ in practice and explains how the
     practical lessons learnt from C++ might be applied to the future use of
     Ada 9X.



-- Sakkinen, M.
      The darker side of C++ revisited.
    Structured Programming, 1992, vol.13, (no.4):155-77.
      Pub type:  Bibliography; Practical.

Abstract: The C++ language is to a high degree a faithful follower of Simula as
     an object-oriented language geared more toward software engineering than
     exploratory programming. The author highlights several of its noteworthy
     good ideas. Like Simula, C++ is designed to be a general-purpose
     procedural language and not 'purely' object-oriented; this is not counted
     as a mortal sin. However, taking the weakly typed and weakly structured
     language C as a base has become an irremediable handicap. Low-level
     concerns have also caused at least one crucial flaw in the object-oriented
     properties of C++. These basic defects have not changed since the author
     first explored the darker side four years ago (M. Sakinnen, 1988). Most,
     although not all, of the numerous features and facilities that have since
     been added to the language are obvious improvements. At the same time,
     they have increased the complexity of C++ so that it is now easily
     comparable to Ada. (Some new features are suggested, nevertheless.) It
     would be regrettable indeed if C++ became the de facto standard of
     object-oriented programming, but this danger looks imminent today.

-- Rosen, J.P.
      What orientation should Ada objects take?.
    Communications of the ACM, Nov. 1992, vol.35, (no.11):71-6.
      Pub type:  Practical.

Abstract: Ada has often been blamed for not being really object oriented, in
     the sense that it provides only static inheritance (through derived
     types), but not a full inheritance mechanism. The 9X revision of the Ada
     standard will introduce inheritance into Ada, but not in the same ways as
     pure OOLs; Ada opponents will certainly take this opportunity to claim
     that the magic label object oriented still does not apply to Ada. The
     author discusses various forms of object orientation and how they apply to
     Ada, and sees how the new features of Ada 9X will impact the design of Ada
     programs. He addresses the issue only from the point of view of a language
     that is directed toward software engineering. He compares Ada mainly to
     two challengers C++ because it is a language that is currently attracting
     considerable attention, and Eiffel because it is a language that has
     specifically been designed to embody the concepts of inheritance in a
     software engineering approach.

-- McCracken, D.D.
      Programming languages in the computer science curriculum. (Twenty-Third
      SIGCSE Technical Symposium on Computer Science Education, Kansas City,
      MO, USA, 5-6 March 1992).
    SIGCSE Bulletin, March 1992, vol.24, (no.1):1-4.
      Pub type:  General or Review.

Abstract: It is important that students understand several programming
     paradigms: imperative (procedural), functional, logic, concurrent,
     object-oriented, fetch/execute machine level. The author discusses some
     programming languages which he feels should be taught in the computer
     science curriculum. These include Pascal, Modula-2, Ada, C, C++ and
     Scheme. He considers their current use in schools.

-- Tang, L.S.
      A CPU scheduling simulation from structured programming to
      object-oriented design. (Twenty-Third SIGCSE Technical Symposium on
      Computer Science Education, Kansas City, MO, USA, 5-6 March 1992).
    SIGCSE Bulletin, March 1992, vol.24, (no.1):129-33.
      Pub type:  Practical.

Abstract: Object-oriented programming has become increasingly popular. The
     author presents a CPU scheduling simulation project that he feels can
     convince students of the benefits of object-oriented design and spur their
     interest. He describes the project and discusses its solutions in three
     levels of abstraction: structured programming using Pascal, object-based
     programming using Ada, and object-oriented programming using C++. He
     presents his experiences in this assignment and explains why the
     object-oriented design is the best approach. This is intended to serve as
     a case study in an object-oriented language course or a programming
     languages course.

-- Harbison, S.
      Safe programming with Modula-3.
    Dr. Dobb's Journal, Oct. 1992, vol.17, (no.10):88-96, 126-7.
      Pub type:  Practical; Product Review (1985- ).

Abstract: Modula-3 is a full-featured language for software engineering and
     object-oriented programming. Feature-for-feature, Modula-3 is on a par
     with Ada and C++, but avoids complexity by simplifying individual features
     like inheritance and generics. Furthermore, Modula-3 is less of a moving
     target because it already has features only now being added to those other
     languages.

-- Bohm, W.; Browne, J.C.; Forslund, D.W.; Goforth, A.; and others.
      Politically incorrect languages for supercomputing-a panel discussion.
    IN:  Proceedings. Supercomputing '92. (Cat. No.92CH3216-9). (Proceedings.
    Supercomputing '92. (Cat. No.92CH3216-9), Minneapolis, MN, USA, 16-20 Nov.
    1992). Los Alamitos, CA, USA: IEEE Comput. Soc. Press, 1992. p. 704-6.
      Pub type:  General or Review; Practical.

Abstract: It is pointed out that the set of languages used to program
     supercomputers has evolved from hand-coded assembler and partially
     vectorized Fortran to include such diverse possibilities as C++, Sisal,
     and even Ada. It is noted that proponents of these languages are often
     fanatical in their support, attempting to share the obvious advantages of
     a particular language with their skeptical colleagues. This paper brings
     together a diverse group of supercomputer and parallel programming experts
     to advocate and debate the merits of several current and emerging
     programming languages and paradigms being used in the supercomputing
     arena. The intent of the panel is not to arrive at a determination of
     'best', but to expand the awareness of the audience that there is a new
     generation of programming languages and techniques emerging that is
     applicable to the supercomputing domain.

-- Baker, H.G.
      Object-oriented programming in Ada83-genericity rehabilitated.
    Ada Letters, Nov.-Dec. 1991, vol.11, (no.9):116-27.
      Pub type:  Practical.

Abstract: A scheme for single-inheritance object-oriented programming in Ada83
     is presented in which many methods are determined at compile time using
     'generic' subprogram overloading. Unlike previous schemes for
     object-oriented programming in Ada83, which rely exclusively on derived
     types for inheritance, the scheme utilizes both derived types and generic
     units, and hence is more powerful. In particular, inheritance schemes
     based on derived types cannot handle the C++ concept of 'virtual
     function', while this scheme determines many of these methods at compile
     time. The results call into question B. Meyer's (1986) conclusions
     regarding the weakness of generic units.

Re: "Subtract C, add Ada"

[Bob Kitzberger]

Laurent Gasser (gasser@masg1.epfl.ch) wrote:

[describes Think Pascal's language-aware editor...]

: All this is done without compiling.  Surprisingly, this feature has 
: not caught on in other environments I know... !?

Rational Apex (and adds semantic browsing, etc...)

--
Bob Kitzberger	        +1 (916) 274-3075	        rlk@rational.com
Rational Software Corp., 10565 Brunswick Rd. #11, Grass Valley, CA 95945
     "Though the boys throw stones at frogs in sport, yet the frogs 
       do not die in sport but in earnest."      - Plutarch

Re: "Subtract C, add Ada"

[Jay Martin]

bishopm@source.asset.com (Michael M. Bishop) writes:

>Why should the relative efficiency between C and Ada be a central topic
>of discussion? (I assume you mean run-time efficiency.) 

I was talking about software development/mantainance efficiency
(which was unclear if you didn't get the whole thread).
And you are totally right the difference in run-time efficiency
between Ada and C negligable.  This is a hot button with me,
with some "hardcore" C types who write shit code because they
are too macho and/or ignorant to let the compiler do the
necessary optimizations.

Jay

Re: "Subtract C, add Ada"

[Erik Svensson]

>  3. uninitialised pointer access
>  4. pointer references to local variables in defunct procedures
>The syntax of Ada removes or reduces errors like 1. and 2. but does
>not really address 3. or 4. (admitedly, 4. is an unnatural practice in
>Ada and would be pretty rare anyway).

Since Ada inititalizes (Sp?) all access variables to Null 3, would seem
to be handled as well, or at least easily handled.

Re: uninitialzed variables

[Richard Kenner]

In article <3f3cq3$4tu@gnat.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes:
>T.E.D. says that all Ada compilers he knows detect uninitialized variables.
>Well not quite, since this problem is of course recursively undecidable. It
>is true that a compiler can detect some obvious cases of uninitialized
>variables, that's not in GNAT yet, but is on our list of nice things to add.

Actually, it is in GNAT since this is done by the GCC optimizer.
Specify the flag -Wuninitialized along with -O or -O2 and it will warn
about variables that appear to be uninitialized.  As Robert points
out, this must be approximate since the problem is undecidable.  In
practice, it tends to have more false positives than false negatives.

Re: "Subtract C, add Ada"

[Norman H. Cohen]

In article <3etund$hnr@miranda.gmrc.gecm.com>, bill@valiant (R.A.L Williams)
writes: 

|> My experience of writing software and running software projects in C
|> highlights four common low-level C errors: 
|>   1. = instead of == and vice versa
|>   2. spurious ; after for(...) or while(...)
|>   3. uninitialised pointer access
|>   4. pointer references to local variables in defunct procedures
|> The syntax of Ada removes or reduces errors like 1. and 2. but does
|> not really address 3. or 4. (admitedly, 4. is an unnatural practice in
|> Ada and would be pretty rare anyway).

No, Ada helps to eliminate all four kinds of errors.

#3: In Ada, all pointers are initialized by default to null.  An attempt
to dereference a null pointer IMMEDIATELY raises Constraint_Error, so
these errors are generally discovered during testing.  (The only way they
could fail to be discovered is if the testing failed to exercise the path
along which the dereference is reached without a prior assignment of a
nonnull value.) In C such an error could remain undiscovered even if the
tests exercise the relevant path.  The arbitrary contents of the
uninitialized pointer might happen not to generate an invalid memory
reference; or the error could occur sporadically and irreproducibly, but
manifest itself only indirectly, much later in the execution of the
program, because of some datum clobbered by assignment to the variable
"pointed to" by an uninitialized pointer.  Then the error might never be
properly attributed to the dereference of an uninitialized pointer.

#4: In Ada 83, access values point only to dynamically allocated
variables, not to declared variables, so the issue does not arise.
In Ada 95, access values can pointed to variables declared aliased, but a
pointer to a local variable of a subprogram can only belong to an access
type that is itself declared inside the subprogram, so the pointer cannot
outlive the variable to which it was pointing.

|> The really strong point about Ada, especially where large teams, or
|> inexperienced coders, are involved is that it strongly encourages
|> the separation of SPECIFICATION from IMPLEMENTATION, and provides
|> a language enforced formalisation of the mechanism. Never mind the
|> commonly expressed rationale behind this, ie. information hiding: 
|> forcing the interfaces between components to be *designed* before
|> attempting to write the implementation, and then encouraging (because
|> of the sheer hassle of not doing it) some sort of formal mechanism
|> if the interfaces have to be changed has got to be the main factor in
|> the success of a project.

I agree.  I also agree with you that it is not hard for programmers who
understand the Ada philosophy to use C in a disciplined way to simulate
Ada packages.  However, violations of the discipline are not easily
recognized or enforced.  (The discipline involves, among other things,
remembering to override the inexcusable C default that functions are
extern rather than static; and always #include'ing a header file with the
declarations of a file's external functions both in the file defining
those functions--to ensure consistency as the file is modified--and in
all files calling such functions.)

But don't underestimate the power of the stupid little errors--the ones
that occur and persist in C programs, but never occur or are eliminated
immediately in Ada programs--to slow a project down or even cause its
failure.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: "Subtract C, add Ada"

[David O'Brien]

R.A.L Williams (bill@valiant) wrote:
: My experience of writing software and running software projects in C
: highlights four common low-level C errors:
:   1. = instead of == and vice versa

I have to wonder.  What if C defined the logical equals operator to be
"=" and the assignment operator to be ":=" just like Ada, Algol, Pascal,
Modula-x, etc?  Would this error still exist???

Quickly thinking about it, I feel that I write a lot more assignment
statements than local statements, couldn't I be in the habit of typing
":=" and thus accidently type that when I meant logical comparison?
Since that would still be a perfectly valid, conforming C program,
the compiler is not required to give any warnings (just like current
practice).  Thus, I would still have the same logic error in my program.
Chances of happening???  Any bodies guess.  So is the problem really
one of symbol choice, or program semantics?


:   2. spurious ; after for(...) or while(...)

This is one area I *really* like about Ada.  However, I feel there
is a much more common programming error (occurs in Pascal too):
     for (...)
	first_action();
	second_action();

The indenting implies that "second_action()" should be part of the
the loop body.  But it isn't.  :-))   So many times I've seen this
in industry.  Every new programmer I work with I try to drill into
their head's "*always* use braces with your if, while, for statements,
even when you have only one thing in your loop body.  For one day a
maintainer will need to add that second thing, and indent like the
above -- forgetting to add the braces."  Many will not listen thinking
they know better.  Tisk, tisk, tisk.  Usually it doesn't take long for
them to get bitten and remember.  Same for Pascal.  I really don't
understand why most languages are designed the Pascal/C way rather
than the Ada way.  Especially since it removes the common ambiguity
of nested if statements.

-- David O'Brien	(dobrien@seas.gwu.edu)

Re: "Subtract C, add Ada"

[Laurent Gasser]

In article <3f4mbe$rud@cronkite.seas.gwu.edu>, dobrien@seas.gwu.edu (David O'Brien) writes:
|> R.A.L Williams (bill@valiant) wrote:
|> : My experience of writing software and running software projects in C
|> : highlights four common low-level C errors:
|> :   1. = instead of == and vice versa
|> 
|> I have to wonder.  What if C defined the logical equals operator to be
|> "=" and the assignment operator to be ":=" just like Ada, Algol, Pascal,
|> Modula-x, etc?  Would this error still exist???

The problem is in the language definition, not in the choic of symbols.
C is one of the rare language I use to allow having an assignment after 
the if statement.  All other languages only allow for a boolean test.

I never saw a good reason for allowing this.

-- 
Laurent Gasser (gasser@dma.epfl.ch)
Computers do not solve problems, they execute solutions.

I know very few ideas worth dying for, none is worth killing.

Re: "Subtract C, add Ada"

[John DiCamillo]

gasser@masg1.epfl.ch (Laurent Gasser) writes:

>In article <3f4mbe$rud@cronkite.seas.gwu.edu>, dobrien@seas.gwu.edu (David O'Brien) writes:
>|> R.A.L Williams (bill@valiant) wrote:
>|> : My experience of writing software and running software projects in C
>|> : highlights four common low-level C errors:
>|> :   1. = instead of == and vice versa
>|> 
>|> I have to wonder.  What if C defined the logical equals operator to be
>|> "=" and the assignment operator to be ":=" just like Ada, Algol, Pascal,
>|> Modula-x, etc?  Would this error still exist???

>The problem is in the language definition, not in the choic of symbols.
>C is one of the rare language I use to allow having an assignment after 
>the if statement.  All other languages only allow for a boolean test.

>I never saw a good reason for allowing this.

Huh? It falls naturally out of two other C rules:

1) an assignment is an expression whose value is equal
   to that of the thing being assigned,
2) any expression that evaluates to integer 0 is false,
   all other expressions are true.

C would have required a special restriction to prevent
assignment in an if-test.  (Note that assignment in a
loop-test is a useful and common idiom in C.)

That said, if this error is anyone's biggest concern
about developing software in C, then that person has
not really tried to develop software in C.  All lan-
guages have warts, even Ada.

-- 
    ciao,
    milo
================================================================
    John DiCamillo                        Pinin' for the fjords?
    milod@netcom.com                  What kind of talk is that?

Re: "Subtract C, add Ada"

[David O'Brien]

Laurent Gasser (gasser@masg1.epfl.ch) wrote:
: In article <3f4mbe$rud@cronkite.seas.gwu.edu>, dobrien@seas.gwu.edu (David O'Brien) writes:
: |> R.A.L Williams (bill@valiant) wrote:
: |> : My experience of writing software and running software projects in C
: |> : highlights four common low-level C errors:
: |> :   1. = instead of == and vice versa
: |> 
: |> I have to wonder.  What if C defined the logical equals operator to be
: |> "=" and the assignment operator to be ":=" just like Ada, Algol, Pascal,
: |> Modula-x, etc?  Would this error still exist???

: The problem is in the language definition, not in the choice of symbols.
: C is one of the rare language I use to allow having an assignment after 
: the if statement.  All other languages only allow for a boolean test.

Yep, that's my point.  The argument of character choice really isn't what
is at the essence of the problem.  Rather it is the language definition.


: I never saw a good reason for allowing this.

Simply the paradigm of C that *every* statement has a value.  And C has
no special logical values.  So C has "values are values" akin to Ford's
offering of the Model-T, "any colour you want, as long as it's black".
I'm guessing Ritchie did this for the same reason as Henry Ford - to
simply things.  Which gave us the situation we have.

In most languages the grammar would be:

	conditional_statement ::=  if <logical_expression> then

Which in C becomes:

	conditional_statement ::=  if ( <expression> ) <statement>

and thus ``<expression>'' must include ``<lvalue> = <expression>''.

-- David O'Brien	(dobrien@seas.gwu.edu)

Re: "Subtract C, add Ada"

[Keith Thompson]

In <3f4mbe$rud@cronkite.seas.gwu.edu> dobrien@seas.gwu.edu (David O'Brien) writes:
> I have to wonder.  What if C defined the logical equals operator to be
> "=" and the assignment operator to be ":=" just like Ada, Algol, Pascal,
> Modula-x, etc?  Would this error still exist???
> 
> Quickly thinking about it, I feel that I write a lot more assignment
> statements than local statements, couldn't I be in the habit of typing
> ":=" and thus accidently type that when I meant logical comparison?
> Since that would still be a perfectly valid, conforming C program,
> the compiler is not required to give any warnings (just like current
> practice).  Thus, I would still have the same logic error in my program.
> Chances of happening???  Any bodies guess.  So is the problem really
> one of symbol choice, or program semantics?

I suspect this error would be rarer if C used ":=" for assignment.
The symbol "=" is used for equality in some languages (Pascal, standard
mathethematical notation, etc.) and assignment in others (Fortran,
C, etc.).  The symbol ":=" is used only for assignment.  I don't think
I've ever accidentally typed ":=" for a comparison in Ada.

Digression:
    I once heard about a relatively obscure language that used ":" as
    a catenation operator.  It also had C-style assignment operators.
    So, naturally, the statement "x := y;" assigned to x the result of
    catenating x and y.
end Digression;

Of course, if C used ":=" for assignment and "=" for comparison, the
opposite error would be likely to occur; people would commonly type
    x = y;
which, instead of assigning the value of y to x, would compare them
and discard the result.  This could be caught by a compiler warning;
an assignment in an expression context sometimes makes sense, but a
comparison in a statement context never does.  It could even be forbidden,
but I suppose that would violate the spirit of C.

Hmm.  How about ":=" and ".EQ."?  8-)}

Please note that this article is not an anti-C flame; it's a theoretical
discussion about programming language syntax design.  Yeah, there's
the ticket.

-- 
Keith Thompson (The_Other_Keith)  kst@thomsoft.com (kst@alsys.com still works)
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
When you're a nail, every problem looks like a hammer.

Re: "Subtract C, add Ada"

[Matt Kennel]

R. William Beckwith (beckwb@ois.com) wrote:
: John DiCamillo (milod@netcom.com) wrote:

: : That said, if this error is anyone's biggest concern
: : about developing software in C, then that person has
: : not really tried to develop software in C.  All lan-
: : guages have warts, even Ada.

: Some languages' warts are really malignant tumors.  ;-)

So, all languages have warts, but only in bad ones do
they metastasize?  ;-)

--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".

Re: "Subtract C, add Ada"

[Robert Dewar]

"Dennis Ritchie once said in an interview that there is *nothing* in the
 C language that keeps compiler writers from issuing stringent warnings
 about stuff that most Ada people take for granted."

Dennis may have said this, but it is misleading. Yes, there is stuff that
Ada people take for granted that C compilers could (and in some compilers
*do*) check for.

But there are lots of things that Ada people take for granted that cannot
be checked in C, there just isn't enough information. C has no separation
of scalar types, no ranges on scalar types, and the ubquitous use of
pointers, and their similarity to arrays means that sophisticated aliasing
analysis is required to even approximate the type checking that occurs
in the context of access types in Ada. There are many other examples.

Re: "Subtract C, add Ada"

[David Moore]

dewar@cs.nyu.edu (Robert Dewar) writes:

>For another example of UNIFY/CONFUSE, does Algol-68 confuse or unify the
>concepts of pointers and variables.

My vote would be for UNIFY. Algol-68 clarified many things that were
implicit in other languages. For example, Algol 68 made it clear that
in the expression:

	A:=A;

The type of A on the left has one more "ref" than the A on the right. I
have found that being cavalier about ref's is a good way to get in
a horrible mess when writing a compiler or debugger. Hence, I believe
anyone who intends to be a language implementor or lawyer should
be familiar with Algol 68.

Unfortunately, it also introduced W-Grammars which I find almost impossible 
to manipulate. They belong to level 3, or perhaps 4 in the complexity 
heirarchy of formalisms:

	Level 1 Formalism.

		You can push instances (eg simple sentences in the language)
                through the formalism in your head.

	Level 2 Formalism.

		You can push through instances on a piece of foolscap while
		sitting at your desk.

	Level 3 Formalism.

		You have to get up and clean off the whiteboard before starting.
		
	Level 4 Formalism.

		You and your colleagues have to go into a conference room and clean
		off the whiteboards. You first have to argue that the phrase 
		"Do not erase" has a scope no larger than the phrase itself.

Fortunately, there is also an "informal" report on Algol 68 which is very
readable.

Re: "Subtract C, add Ada"

[Norman H. Cohen]

Just yesterday I made a one-character typo in a C program (don't ask; it
puts food on the table) that preserved the legality of the program but
rather radically altered its behavior.  I meant to type

   for (i=0; i<10; i++)

but my finger slipped off the shift key when I was typing "<", so it came
out

   for (i=0; i,10; i++)

which tests for loop termination by evaluating i, discarding that value,
evaluating 10, and leaving the loop when 10 equals zero (i.e., never).

What a language!

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: "Subtract C, add Ada"

[R. William Beckwith]

John DiCamillo (milod@netcom.com) wrote:
: beckwb@ois.com (R. William Beckwith) writes:

: >John DiCamillo (milod@netcom.com) wrote:

: >: That said, if this error is anyone's biggest concern
: >: about developing software in C, then that person has
: >: not really tried to develop software in C.  All lan-
: >: guages have warts, even Ada.

: >Some languages' warts are really malignant tumors.  ;-)

: Did you have something useful to follow that up with?

No, but I'll make the attempt since you're interested.

: Do you disagree with either of the sentences you were
: responding to?  Do you feel that I am misrepresenting
: the relative quality of the two languages in question?

Not really and yes.  I agree everything has warts.
It has been my experience that while Ada's occasional
warts can be annoying, C's occasional warts can be deadly.

... Bill

Re: "Subtract C, add Ada"

[Samuel Mize]

In article <3f5s92$3id@info.epfl.ch>,
Laurent Gasser <gasser@masg1.epfl.ch> wrote:
>
>The problem is in the language definition, not in the choic of symbols.
>C is one of the rare language I use to allow having an assignment after 
>the if statement.  All other languages only allow for a boolean test.
>
>I never saw a good reason for allowing this.
>

It's a question of who optimizes your code.  In the 60s,
when C was developed, compilers *couldn't* optimize code,
so the programmer had to.  Many apparently-bizarre C
capabilities are there to support optimization level -1
(programmer does the optimizations).

Consider the common C idiom to copy a null-terminated
array, usually a string [syntax may not be quite right]:

     while (*a++=*b++);

Recall that C considers 0 false, a null character is integer
0, and an assignment returns what was assigned.  This loop
condition copies the character at address b to address a,
increments both, and exits when a null was copied.  There is
no statement inside the loop.

This is more efficient, with a non-optimizing compiler, than

  while (*a)
    { *a = *b; a=a+1; b=b+1}; /*or whatever is right syntax*/

because
* The operator ++ increments the value of while it's still
  in a register.  The second code reads a from memory to
  do the character assign, reads it again to increment it.

* ++ can use the assembler's increment instruction.  a=a+1
  could not.

* Using the assignment as the loop expression indirectly
  directs the compiler to keep the result of the assignment
  in a register for reuse in the expression, instead
  of writing it to memory, then reading it.

Thus, with a lot of man-hours, expertise and skull-sweat,
someone using a basic C compiler can come within an order
of magnitude of the efficiency of someone using a half-good
optimizing Ada compiler.  Often.

Of course, if you only *read* the code, and don't *run*
it, it looks like the C is more optimized, because you can
*see* the optimizations.

With Ada you write less-optimized-looking code, and trust
the compiler.  (But verify.)

>-- 
>Laurent Gasser (gasser@dma.epfl.ch)
>Computers do not solve problems, they execute solutions.
>
>I know very few ideas worth dying for, none is worth killing.

I dunno, I've killed quite a few ideas in my time :-)

Sam Mize - smize@starbase.neosoft.com

Re: "Subtract C, add Ada"

[Samuel Mize]

In article <3fdcoi$chn@miranda.gmrc.gecm.com>,
R.A.L Williams <bill@valiant> wrote:
>
>Robert Dewar wrote..
>> Bill comments that for his points 3. and 4.
>> 
>>   3. uninitialised pointer access
>>   4. pointer references to local variables in defunct procedures
>> 
>> "The syntax of Ada .. does not really address 3. or 4."
>> 
>> Taking point 3, it is impossible to have an uninitialized pointer in Ada,
>> all pointers are initialized to null, and any attempt to use a null pointer,
>> i.e. to dereference it, will cause a constraint error. Seems like pretty
>> complete protection to me.
>
>Yes, you're right, Ada *guarantees* a run time crash, in C/C++ it's just very
>likely. ...

The rest of your post suggests that you understand this, but I will
point it out for the less-versed souls reading this newsgroup:

Ada does not guarantee a run-time crash.  It guarantees that the
program will identify, and respond to, the error.  If you have
exception handlers properly in place, they can do some default
action; e.g., you can drop to a degraded mode.  In C/C++, you
can (1) dereference a bad value and merrily use it (2) write to
an arbitrary address (e.g., the OS or your instruction pointer),
creating phantom bugs in other code (3) seg error (core dump).

Even a well-designed C program can provide these exciting
opportunities, since the occasional human error is unavoidable,
not to mention hardware failures.

In Ada, you have to make the original error, *and* not provide
a fall-back in your exception handlers.  Only if you do both
will you get a run-time crash.  Otherwise, you will get a
run-time performance degradation.

>likely. It's still not a compile time check so you're relying on the
>quality of your run time environment to tie down where the problem
>occurs. ...

True.  Wish we could solve the problem of uninitialized variables,
'cause then we'd know how to solve undecidable problems.

>occurs. Of course, in embedded systems you don't want *any* exceptions,
>no matter how cleanly you handle them!

Sure you do, if there was a programmer error, or a hardware glitch,
or a bad memory location, etc.  These are the things you don't want.
Given that you can't eliminate those, oh *boy* do you want exceptions,
given the alternative (core dump at 30,000 feet -- how do I reboot
my F-16?!?!?!?)

>... I was just trying to point out that using Ada is no substitute
>for good engineering practice in design and coding.
>

Very true.  I'm pointing out that Ada provides tools for good
engineering practice that are not available in C/C++ .

>
>
>Bill Williams
>

Sam Mize - smize@starbase.neosoft.com

Re: "Subtract C, add Ada"

[RonaldS60]

Gary Frankel (gfrankel@rational.com) wrote
>As of late 1989, I was involved in a commerical Ada optimizing 
>compiler... We published results on a wide variety of benchmarks
>(Hennessey,etc) that showed that the Ada compiler was producing
>better code than any commercially available C compiler at that time
>and far better than most C compilers.  This was true for workstations
>and cross compilers.
>
>I cant vouch to the same degree for the current state of the art
>since I havent done the same studies recently, but I believe
>that you will find tha the optimizing Ada compilers can produce
>comparable or better code than C compilers.  I have also noticed
>that a number of C++ compilers produce poorer code - probably due
>to the current level of maturity.

About two years ago a IEEE article (in one of the s/w engineering
journals) compared the percentages of dead code (I assume using some
reachability algorithm) between Fortran, C, and C++.  The numbers
were suprising (to say the least) and indicated that while Fortran
had the least dead code (followed by C) C++ could have upto 60%-75%
dead code.  The exact quantity being undecidable in a static analysis
due to virtual function calls.  This research hasn't had any obvious
effect on the C++ crowd (or any of the OO people) that I have seen.

>Generally, an optimizing Ada compiler is actually at an advantage over
>C compilers due to Ada sources providing more useful type information
>and the aliasing problems of C.  Ada compilers will tend to 
>compile more slowly since they do considerably more checking than
>C compilers.

One of the problems with aliasing is covered in an article titled 
'The Undecidability of Aliasing' by G. Ramalingam in ACM Transactions
on Programming Languages and Systems, vol. 16 no. 5, September 1994.

>So, I think that anyone who does a careful study will simply not
>find that C has any advantages in code efficiency over Ada at all
>(at least on any program more than a few short lines).

Actually there was an article around 1989 to 1991 covering the 
difference between two programs (that did the same thing) written in
C and Ada.  They were both compiled on the best compilers that could
be found.  C won for overall speed, by less than 2% when runtime 
checking was disabled (as it could be when the program was validated.)
A 1% to 2% difference in speed isn't much price to pay when the
overall development cycle is shortened (especially in testing) as
much as Ada allows (when compared to C.)  Just think how nice it
would have been if that company in Redmond had used Ada instead of
C (oooh, software that actually works! and on time! ;{))).

>-- Gary Frankel
>
>
>Mitch Gart (mg@asp.camb.inmet.com) wrote:
>: Jay Martin (jmartin@oahu.cs.ucla.edu) wrote:
>
>: : I read the abstracts to these papers before I posted, there is not
>: : one peep about the relative efficiency between C and Ada which
>: : should be the central topic of discussion in my opinion.
>
>: I wrote a paper on this, which is now pretty dated, but still might
>: possibly be of interest:
>
>: "Benchmarking Ada, C, and Pascal", SigAda conference, July 1986,
>: Pittsburgh.
>
>:  Mitch Gart


Ron
======================================================
Computers now make it possible to make more mistakes
more efficiently than ever before possible.
======================================================

"Subtract C, add Ada"

[R.A.L Williams]

[Our news system broke down earlier this week so I don't know
 whether this message got out. If it did I apologise for the
 wasted bandwidth.

 Bill Williams]

Robert Dewar wrote..
> Bill comments that for his points 3. and 4.
> 
>   3. uninitialised pointer access
>   4. pointer references to local variables in defunct procedures
> 
> "The syntax of Ada .. does not really address 3. or 4."
> 
> Taking point 3, it is impossible to have an uninitialized pointer in Ada,
> all pointers are initialized to null, and any attempt to use a null pointer,
> i.e. to dereference it, will cause a constraint error. Seems like pretty
> complete protection to me.

Yes, you're right, Ada *guarantees* a run time crash, in C/C++ it's just very
likely. It's still not a compile time check so you're relying on the
quality of your run time environment to tie down where the problem
occurs. Of course, in embedded systems you don't want *any* exceptions,
no matter how cleanly you handle them! I'm not saying that we necessarily
want to go to a language which either doesn't allow pointers (yuck!) or
constrains their use to such an extent that compile time checks are
feasible; I was just trying to point out that using Ada is no substitute
for good engineering practice in design and coding.

> With regard to point 4, ther is no way to get pointer references to local
> variables in Ada 83 (except use of 'Address, and non-portable maybe-works,
> maybe-doesn't unchecked conversion of the address to an access type, which
> really doesn't count). Certainly students (and most other Ada programmers)
> should be forbidden from using such constructs (the use of 'Address, and
> indeed of unchecked conversion of addresses to access types is permissible
> in some situations, but taking the 'Address of locals in a subprogram is
> pretty dubious).

Again, you're right BUT, 'ADDRESS is something you need to do fairly
often when interfacing to foreign languages. Sorry, don't want to start a
religious argument about libraries etc. it's just a fact of life.

I agree whole heartedly about restricting the constructs used by 'novice'
programmers or those coding for `critical' environments.

> In Ada 95, it is indeed possible to take the 'Access of local variables,
> provided they are marked aliased, but the accessibility rules make it
> impossible to have dangling pointers. Dangling pointers can be created
> by the use of Unchecked_Access, but this is in the same category as
> Unchecked_Conversion, to be used with great care in rare cases.

I'm looking forward to trying out Ada95. Got GNAT 2.0 up and going on
a SPARC station that I have occasional access to. I'm really looking
forward to the HP700 port because that's what our local network is.

Thanks for the feedback.

Bill Williams

"Subtract C, add Ada"

[R.A.L Williams]

In article <3f5s92$3id@info.epfl.ch> you wrote:
: In article <3f4mbe$rud@cronkite.seas.gwu.edu>, dobrien@seas.gwu.edu (David O'Brien) writes:
: |> R.A.L Williams (bill@valiant) wrote:
: |> : My experience of writing software and running software projects in C
: |> : highlights four common low-level C errors:
: |> :   1. = instead of == and vice versa
: |> 
: |> I have to wonder.  What if C defined the logical equals operator to be
: |> "=" and the assignment operator to be ":=" just like Ada, Algol, Pascal,
: |> Modula-x, etc?  Would this error still exist???

: The problem is in the language definition, not in the choic of symbols.
: C is one of the rare language I use to allow having an assignment after 
: the if statement.  All other languages only allow for a boolean test.

: I never saw a good reason for allowing this.

I think there are three reasons:
 1. It allows your code to be more compact. Many people think this is
    a disadvantage, and so it is if the code will be read by comparative
    novices, but it can improve readability to C experts who are 
    expecting such tricks.

    NB DONT confuse compactness with poor layout! I find that, for example:

       while ((c = getchar()) == ' ')
       {
          /* count spaces */
       }

    is clearer than the 'expanded' alternative (to *me* :-).

 2. All expressions in C have a value. Conditional tests succeed on 
    non-zero and fail on zero. Therefore, to maintain orthogonality, 
    as far as possible, there is no reason to exclude an assignment 
    expression from a condition.
   
 3. Finally, I suspect, this can simplify the optimisation algorithms 
    in the compiler.

Personally, the lack of this sort of compactness in Ada, and things like
pre- and post-increment/decrement are one of my minor gripes about the
language. OK, its no big thing to write:

    P(I) := Q(I);
    I := I + 1;

instead of
 
    *p++ = *q++;

but I actually *do* find the C representation easier/better etc. (perhaps
I'm wierd?)

: -- 
: Laurent Gasser (gasser@dma.epfl.ch)
: Computers do not solve problems, they execute solutions.

: I know very few ideas worth dying for, none is worth killing.

Very true, but quite a few are worth a pint in the pub.

Bill Williams

Re: "Subtract C, add Ada"

[Renaud HEBERT]

In article <3fo2ot$su2@miranda.gmrc.gecm.com>, bill@valiant (R.A.L Williams) writes:
|> 
|> In article <3f5s92$3id@info.epfl.ch> you wrote:
|> : In article <3f4mbe$rud@cronkite.seas.gwu.edu>, dobrien@seas.gwu.edu (David O'Brien) writes:
|> : |> R.A.L Williams (bill@valiant) wrote:
|> : |> : My experience of writing software and running software projects in C
|> : |> : highlights four common low-level C errors:
|> : |> :   1. = instead of == and vice versa
|> : |> 
|> : |> I have to wonder.  What if C defined the logical equals operator to be
|> : |> "=" and the assignment operator to be ":=" just like Ada, Algol, Pascal,
|> : |> Modula-x, etc?  Would this error still exist???
|> 
|> : The problem is in the language definition, not in the choic of symbols.
|> : C is one of the rare language I use to allow having an assignment after 
|> : the if statement.  All other languages only allow for a boolean test.
|> 
|> : I never saw a good reason for allowing this.
|> 
|> I think there are three reasons:
|>  1. It allows your code to be more compact. Many people think this is
|>     a disadvantage, and so it is if the code will be read by comparative
|>     novices, but it can improve readability to C experts who are 
|>     expecting such tricks.
|> 
|>     NB DONT confuse compactness with poor layout! I find that, for example:
|> 
|>        while ((c = getchar()) == ' ')
|>        {
|>           /* count spaces */
|>        }
|> 
|>     is clearer than the 'expanded' alternative (to *me* :-).
|> 
|>  2. All expressions in C have a value. Conditional tests succeed on 
|>     non-zero and fail on zero. Therefore, to maintain orthogonality, 
|>     as far as possible, there is no reason to exclude an assignment 
|>     expression from a condition.
|>    
|>  3. Finally, I suspect, this can simplify the optimisation algorithms 
|>     in the compiler.
|> 
|> Personally, the lack of this sort of compactness in Ada, and things like
|> pre- and post-increment/decrement are one of my minor gripes about the
|> language. OK, its no big thing to write:
|> 
|>     P(I) := Q(I);
|>     I := I + 1;
|> 
|> instead of
|>  
|>     *p++ = *q++;
|> 
|> but I actually *do* find the C representation easier/better etc. (perhaps
|> I'm wierd?)

Even if I like C, I think that this ++ is ugly and I'm glad that there isn't such
a thing in Ada. On the other hand what do you think about the operators += *= ...
They make thing shorter AND easier to read, a += 5; means exactly add 5 to a.
So don't you think that these construct have their place in Ada.

|> 
|> : -- 
|> : Laurent Gasser (gasser@dma.epfl.ch)
|> : Computers do not solve problems, they execute solutions.
|> 
|> : I know very few ideas worth dying for, none is worth killing.
|> 
|> Very true, but quite a few are worth a pint in the pub.
|> 
|> Bill Williams
|> 

-- 
Renaud HEBERT		e-mail: Renaud.Hebert@prism.uvsq.fr

Re: "Subtract C, add Ada"

[Garlington KE]

Samuel Mize (smize@Starbase.NeoSoft.COM) wrote:
: Sure you do, if there was a programmer error, or a hardware glitch,
: or a bad memory location, etc.  These are the things you don't want.
: Given that you can't eliminate those, oh *boy* do you want exceptions,
: given the alternative (core dump at 30,000 feet -- how do I reboot
: my F-16?!?!?!?)

Actually, as one of the software engineers who developed the F-16 digital
flight control system (as well as the YF-22A flight control system), I can
say with confidence that you _don't_ want exceptions for a human programmer
error, since no one has figured out an adequate response to them in a 
dynamic feedback system like a flight control system. It doesn't matter what
happens in the other cases since there is physical redundancy and output
monitoring as a part of the total system.

However, for systems with the capability to degrade cleanly, exceptions are
a very good thing and in fact are widely used in embedded avionics software.

--------------------------------------------------------------------
Ken Garlington                  GarlingtonKE@lfwc.lockheed.com
F-22 Computer Resources         Lockheed Fort Worth Co.

If LFWC or the F-22 program has any opinions, they aren't telling me.

Re: "Subtract C, add Ada"

[Robert Dewar]

Laurent Gasser says:

>"Personally, the lack of this sort of compactness in Ada, and things like
> pre- and post-increment/decrement are one of my minor gripes about the
> language. OK, its no big thing to write:
>
>     P(I) := Q(I);
>     I := I + 1;
>
> instead of
>
>     *p++ = *q++;
>
> but I actually *do* find the C representation easier/better etc. (perhaps
> I'm wierd?)"

The trouble with these notations in C is that they work better with short
variable names, as in the example above. This is reminiscent of typical
mathematical notations (like ! for factorial) that also are predicated on
typical mathematical style of one character variables like x. Now look at

    Next_Predicted_Value (Iteration_Index) :=
      Previous_Calculated_Value (Iteration_Index);

and

   *Next_Predicted_Value++ = *Previous_Calculated_Value++;

There are two problems with the second form. First the * and ++ seem to get
a bit lost with the long names. Second, we are missing the name
Iteration_Index which may be quite helpful in understanding what is going on.

Note also that the C style is implying the use of pointers, which are less
comfortable than the use of arrays, because the pointers could be pointing
to anything, while we know what is involved with the arrays.

All in all, the Ada in the second example seems much clearer, and of course
once you use long identifiers, the advantage of the compact notation is
reduced.

There is no rule saying use long identifiers in Ada, and use short identifiers
in C (and I am sure we have all seen code with short identifiers in Ada, and
long identifiers in C), but it is not an accident that even though there are
no rules, there are effectively stylistic customs in these directions, and
I think that the neat compact C syntax gizmos are at least partly responsible.

Re: "Subtract C, add Ada"

[David O'Brien]

In article <3fnf28$s3f@Starbase.NeoSoft.COM> you wrote:
: It's a question of who optimizes your code.  In the 60s,
: when C was developed, compilers *couldn't* optimize code,
: so the programmer had to.  Many apparently-bizarre C
: capabilities are there to support optimization level -1
: (programmer does the optimizations).

C was designed in the 70's.  The earliest reference I could find to it
is the cc(1) UNIX 3rd Edition man page dated 3/15/72 from "A Quarter
Century of Unix".  The language from which C developed, B, was created
in 1970.  And the only published document on the B language, "CSTR #8 -
The Programming Language B", is dated Jan 1973.  BCPL, which B came
from, is from 1969.

So, I think that "compilers *couldn't* optimize code" may be an over
generalization.  Is this _really_ the case for 1970's compiler
technology?

: Consider the common C idiom to copy a null-terminated
: array, usually a string [syntax may not be quite right]:

:      while (*a++=*b++);

I am curious about programming culture.  Notice that when someone writes
something in C they feel they have to remove all white space.  When they
write in Ada they put in plenty and use [very] long names for every
thing.  Why is that???  No wonder people say C is hard to read.


: This is more efficient, with a non-optimizing compiler, than

:   while (*a)
:     { *a = *b; a=a+1; b=b+1}; /*or whatever is right syntax*/

: because
: * The operator ++ increments the value of while it's still
:   in a register.  The second code reads a from memory to
:   do the character assign, reads it again to increment it.

You are making a *major* assumption about the CPU this is running on.
On many smaller uP's there isn't that many registers.

: * ++ can use the assembler's increment instruction.  a=a+1
:   could not.

Since adding 1 to variable is so common place, it is trivial to add this
type of optimization (even in your parser).

: * Using the assignment as the loop expression indirectly
:   directs the compiler to keep the result of the assignment
:   in a register for reuse in the expression, instead
:   of writing it to memory, then reading it.

Again, you really are thinking with a preconceived notion of your
hardware.

-- David O'Brien	(dobrien@sea.gwu.edu)

Re: "Subtract C, add Ada"

[David O'Brien]

R.A.L Williams (bill@valiant) wrote:
: I think there are three reasons:
:  1. It allows your code to be more compact. Many people think this is
:     a disadvantage, and so it is if the code will be read by comparative
:     novices, but it can improve readability to C experts who are 
:     expecting such tricks.
:
:     NB DONT confuse compactness with poor layout! I find that, for example:
:
:        while ((c = getchar()) == ' ') { /* count spaces */ }
:
:     is clearer than the 'expanded' alternative (to *me* :-).

BINGO!!!  Readability, like beauty, is in the eye of the beholder.  An
instructor here made the statement "Pascal is easier to read then C".  I
don't think so.  In fact I got a D on a midterm because of it.  I was
the only person in my soph intro CS class using C instead of Pascal, so
all the code fragments were in Pascal.  To this day, I still can't read
Pascal's pointer syntax.  Readability is what you are familiar with.
Both of the C code fragments are very familiar to me and I find *very*
easy to read (except for the lack of white space in the first one).

The same is true for Natural language.  I can speak/read/write some
Vietnamese.  Vietnamese is a very regular language, and the spelling
rules are never broken.  The language is purely phonetic, making it
quick to learn to pronounce words.  However, I find English easier to
read/write because of my added familiarity with English.  And, it has even
more warts than people state here about C.  :-))

I am tired of novice C users always saying this construct is bad, and
that construct is bad.  And I don't care to program in C using only
constructs that a novice would understand at first glance.  Ours is a
professional environment and certain level of proficiency should be
expected.  If a high school kid off the street could program like an
expert, then why are we getting degrees and such?

Writing ``for (p = head; p; p = p->next) { /* process list */ }''
Is quite clear to me, but others will probably disagree.  But I find the
way of reading a file in Ada to quite idiomatic.  At least I was
taught to enclose the reading from the file in a loop with an exception
handler w/in the loop.  When the exception would be raised when an attempt
to read past EOF, then close the file and process what ever your read in.

-- David O'Brien	(dobrien@seas.gwu.edu)

Re: "Subtract C, add Ada"

[Robert Dewar]

"compilers couldn't optimize code"

what is meant here is "C compilers didn't optimize code", and this was partly
a matter of philosophy, the idea that C compilers should be simple and do
what you say, and NOT rely on optimization.

Optimization technology was well developed even in the late 60's. Fortran-2
for the 7094 did a remarkably good job of optimizing loops. Fortran-H
was contemporary with early C compilers, and was very aggressive in optimizing
typical Fortran code.

Re: "Subtract C, add Ada"

[Jay Martin]

>: The problem is in the language definition, not in the choic of symbols.
>: C is one of the rare language I use to allow having an assignment after 
>: the if statement.  All other languages only allow for a boolean test.

>: I never saw a good reason for allowing this.

Right!

>I think there are three reasons:
> 1. It allows your code to be more compact. Many people think this is
>    a disadvantage, and so it is if the code will be read by comparative
>    novices, but it can improve readability to C experts who are 
>    expecting such tricks.
>
>    NB DONT confuse compactness with poor layout! I find that, for example:
>
>       while ((c = getchar()) == ' ')
>       {
>          /* count spaces */
>       }
>
>    is clearer than the 'expanded' alternative (to *me* :-).

"C expert" does not equal professional programmer.  Just because
someone can read arcane poorly designed code does not mean he is 
competent software engineer.  In fact, I would say that many C
programmers are basically are very incompetent and undeciplined
programmers. No one should write code to please idiots who want
tricks. 

Yuck:
-- We have a function that changes state "getchar()".
-- We have an boolean expression that has a side-effect to c.
-- We have to look twice at the expression to see that we are comparing
   the results of "getchar()" and not "c" (which is just there for
   the ride). 

How about:

loop
  GetChar(C);
  exit when (C /= ' '); 
  ...
end loop;

Sure it has an exit in the loop, it always cracks me up when
programmers who have side-effects galore in their programs start
whining about the "impurity" of having an exit in a loop

> 2. All expressions in C have a value. Conditional tests succeed on 
>    non-zero and fail on zero. Therefore, to maintain orthogonality, 
>    as far as possible, there is no reason to exclude an assignment 
>    expression from a condition.

But we are arguing that languages should not have side-effects in
expressions and thus an assignment should not an expression or sub-
expression or return a value.  So "All expressions in C have a value"
is not gospal it is just another bad language design decision made by
certain incompetent language designers (K&R).  The reason to not to
allow it is that it causes programming errors and terse garbage
code.  
   
> 3. Finally, I suspect, this can simplify the optimisation algorithms 
>    in the compiler.

Ack!  Compiler:
  Warning: Due to that you did not imbed your assignments in boolean
           expression on line 2432, this compiler cannot optimize 
           that statement. Sorry about that.

Again ignorance of compiler optimization abounds.  From what I have
seen the "too macho to trust the compiler" attitude dominates the
industry.  Processors have multiple processing units to schedule and
pipelines filled to minimize stalls.  I just don't see the "optimized
C" computational model as being relevant any more. 

(4)
>Personally, the lack of this sort of compactness in Ada, and things like
>pre- and post-increment/decrement are one of my minor gripes about the
>language. OK, its no big thing to write:

>    P(I) := Q(I);
>    I := I + 1;

>instead of
 
>    *p++ = *q++;

>but I actually *do* find the C representation easier/better etc. (perhaps
>I'm wierd?)

Yup, pretty weird.  Compactness/terseness does not equal better
readibility.   Arrays are higher level than pointers and will be bounds
checked by most adequate languages.  Pointer arithmetic in my opinion
is yet another crap idea from the K&R bozos.

Another C guy:

>BINGO!!!  Readability, like beauty, is in the eye of the beholder.  An
>instructor here made the statement "Pascal is easier to read then C".  I
>don't think so.  In fact I got a D on a midterm because of it.  I was
>the only person in my soph intro CS class using C instead of Pascal, so
>all the code fragments were in Pascal.  To this day, I still can't read
>Pascal's pointer syntax.  Readability is what you are familiar with.
>Both of the C code fragments are very familiar to me and I find *very*
>easy to read (except for the lack of white space in the first one).

Yeah, all things are relative, all is a matter of opinion, all ideas
are of equal merit, etc. (We don't want to upset anyone)

Got a D, good, at least some instructors out there care about
teaching programming / language design.  Wow! so mentally rigid can't
read Pascal's elegant pointer syntax.  Gee, maybe the professor might
just know more than you, maybe when you take a class you should
try to learn something.  Guess you didn't want to learn good
program structure and clean language syntax and semantics. 

>I am tired of novice C users always saying this construct is bad, and
>that construct is bad.  And I don't care to program in C using only
>constructs that a novice would understand at first glance.  Ours is a
>professional environment and certain level of proficiency should be
>expected.  If a high school kid off the street could program like an
>expert, then why are we getting degrees and such?

Again, we have a incorrect correlation here between "professional
programmer" and C hacker.  "Novices" here are equated with
incompetent programmers when they may just be expert software
engineers who fully understand good programming language and software
design.  Why should we want to become proficient in old poorly
designed languages which is hard to learn when we can learn something
that is well designed that we can learn quicker and also have better
productivity in the long run.  I can get no joy from becoming
proficient in crap.  In my opinion, no person should get a
computer science degree with out understanding the flaws of C and
other popular poorly designed languages and systems.    

Heh, (C Idiom == Idiotm)

>Writing ``for (p = head; p; p = p->next) { /* process list */ }''

Ptr := Head;
while (Ptr /= null) loop
  ...
  Ptr := Ptr.Next;
end loop;

(My Ada is rusty, I only program in C++ now)

>Is quite clear to me, but others will probably disagree.  But I find the
>way of reading a file in Ada to quite idiomatic.  At least I was
>taught to enclose the reading from the file in a loop with an exception
>handler w/in the loop.  When the exception would be raised when an attempt
>to read past EOF, then close the file and process what ever your read in.

Actually, depending on exceptions to catch the EOF condition is
bad Ada style as you are depending on an exception for normal program
control.
----------

Okay I was harsh.  But these "C" attitudes of programming are pretty
much the norm in industry and I find this very distressing.  In my
opinion, the Computer Science community must admit their total
failure to teach or even understand or form a consensus about
good software construction and programming language design. 

"Subtract C, add Ada"

[R.A.L Williams]

In article <3feevh$615@gnat.cs.nyu.edu> Robert Dewar wrote:
: "Dennis Ritchie once said in an interview that there is *nothing* in the
:  C language that keeps compiler writers from issuing stringent warnings
:  about stuff that most Ada people take for granted."

: Dennis may have said this, but it is misleading. Yes, there is stuff that
: Ada people take for granted that C compilers could (and in some compilers
: *do*) check for.

: But there are lots of things that Ada people take for granted that cannot
: be checked in C, there just isn't enough information. C has no separation
: of scalar types, no ranges on scalar types, and the ubquitous use of
: pointers, and their similarity to arrays means that sophisticated aliasing
: analysis is required to even approximate the type checking that occurs
: in the context of access types in Ada. There are many other examples.

Ranges - no, but my Microsoft C compiler certainly *does* warn me when I
 - mix signed and unsigned integers (of course, Ada83 doesn't have unsigned)
 - assign the result of 'long' expressions to shorts or chars etc.
 - perform 'unchecked conversion' between integers and pointers

There are probably other things as well, but these are certainly some of the
gripes it comes up with when I try to port typical UNIX C code to WIN32.

I agree with Dennis Ritchie, If I go to the trouble of typedef'ing a new
type, there is nothing to stop the compiler from griping at me if I
do something inappropriate with it. This is mainly a compiler issue, not
a language issue.

Bill Williams

Re: "Subtract C, add Ada"

[Andrew McConnell]

In article <3fv6lb$f4u@oahu.cs.ucla.edu>,
Jay Martin <jmartin@oahu.cs.ucla.edu> wrote:
>
>Okay I was harsh.  But these "C" attitudes of programming are pretty
>much the norm in industry and I find this very distressing.  In my
>opinion, the Computer Science community must admit their total
>failure to teach or even understand or form a consensus about
>good software construction and programming language design. 
>

Yes, that was pretty harsh....

I have to agree that the CS community has really dropped the ball.
I've been reading many of the "jobs" newsgroups lately and see posting
after posting for "Software Engineers" who have n years programming in
language x.  My question: If they're hiring software engineers why do
they INSIST on experience in language x.  Isn't computer
science/software engineering language independent to a great extent?

I feel that they are _some_ language factors that you have to take
into account when doing S/W design, but a good SWE doesn't get hung up
on language choice.  

-- 
Andrew R. McConnell
mcconnel@source.asset.com

Re: "Subtract C, add Ada"

[Norman H. Cohen]

In article <3frqpg$re5@cronkite.seas.gwu.edu>, dobrien@seas.gwu.edu
(David O'Brien) writes: 

|> In article <3fnf28$s3f@Starbase.NeoSoft.COM> you wrote: 
|> : It's a question of who optimizes your code.  In the 60s,
|> : when C was developed, compilers *couldn't* optimize code,
|> : so the programmer had to.  Many apparently-bizarre C
|> : capabilities are there to support optimization level -1
|> : (programmer does the optimizations).
...
|> : Consider the common C idiom to copy a null-terminated
|> : array, usually a string [syntax may not be quite right]: 
|>
|> :      while (*a++=*b++);
|>
|> I am curious about programming culture.  Notice that when someone writes
|> something in C they feel they have to remove all white space.  When they
|> write in Ada they put in plenty and use [very] long names for every
|> thing.  Why is that???  No wonder people say C is hard to read.

It's because the primitive compilers of the 1970's were incapable of
optimizing away the whitespace. ;-)

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: "Subtract C, add Ada"

[John Cosby - The Coz]

David O'Brien (dobrien@seas.gwu.edu) wrote:
: In article <3fnf28$s3f@Starbase.NeoSoft.COM> you wrote:
: : It's a question of who optimizes your code.  In the 60s,
: : when C was developed, compilers *couldn't* optimize code,
: : so the programmer had to.  Many apparently-bizarre C
: : capabilities are there to support optimization level -1
: : (programmer does the optimizations).

: C was designed in the 70's.  The earliest reference I could find to it
: is the cc(1) UNIX 3rd Edition man page dated 3/15/72 from "A Quarter
: Century of Unix".  The language from which C developed, B, was created
: in 1970.  And the only published document on the B language, "CSTR #8 -
: The Programming Language B", is dated Jan 1973.  BCPL, which B came
: from, is from 1969.

The July-August 1978 edition of "The Bell System Technical Journal" contains
an article by Ritchie, Johnson, Lesk, and Kernughan entitled "The C 
Programming Language."  In this article they state that B was written in 1970
by Ken Thompson "for the first UNIX system on the PDP-11."  They go on to
discuss how the introduction of types was a major departure from BCPL and B
and mention in passing that C was created "circa 1972."  An interesting 
article, which discusses many of the issues debated during the evolution 
of Ada into Ada95 from a much "earlier" point of view.  Fun to see how 
far we've come.

John

Re: "Subtract C, add Ada"

[Robert Firth]

In article <3fo2ot$su2@miranda.gmrc.gecm.com> bill@valiant (R.A.L Williams) writes:

I guess I'm about to show my ignorance of C, but I'm very confused
bt this post.

> 1. It allows your code to be more compact.

>    NB DONT confuse compactness with poor layout! I find that, for example:
>
>       while ((c = getchar()) == ' ')
>       {
>          /* count spaces */
>       }
>
>    is clearer than the 'expanded' alternative (to *me* :-).

Nope, I find this totally unclear.  Who's counting?  Unless I've missed
an invisible declaration, initialisation, and increment, the above
code *doesn't* count spaces, it skips them.  And if that is its
purpose, what's the point of the variable 'c'?  Why not just say

	WHILE getchar = ASCII.SP LOOP null; END LOOP;

Though, again, I'd much rather write this:

	LOOP
	   get(c);
	   EXIT WHEN c /= ASCII.SP;
	END LOOP;

since the postcondition I almost certainly want to establish - that
c holds the next non-space character - is written right there in the code.

Note also that if there are *no more* non space characters, the C code
dies in an infinite loop, while the Ada code automatically does the
right thing, namely raises the END_ERROR exception.

>OK, its no big thing to write:
>
>    P(I) := Q(I);
>    I := I + 1;
>
>instead of
> 
>    *p++ = *q++;
>
>but I actually *do* find the C representation easier/better etc. (perhaps
>I'm wierd?)

Again, I don't see it.  The Ada code makes it clear that *corresponding*
elements of the array Q are being copied into P - though, of course,
a real Ada programmer (TM) would have written just P := Q.  The C code
doesn't make that clear - you're going to have to ferret out the
initialisations of p and q to determine that.  And if you worry about
the correctness of the copy - for instance, whether P and Q are the
same size - that's surely going to be a lot easier to establish in Ada.

Re: "Subtract C, add Ada"

[Bob Kitzberger]

David O'Brien (dobrien@seas.gwu.edu) wrote:

: I am tired of novice C users always saying this construct is bad, and
: that construct is bad.  And I don't care to program in C using only
: constructs that a novice would understand at first glance.  Ours is a
: professional environment and certain level of proficiency should be
: expected.  If a high school kid off the street could program like an
: expert, then why are we getting degrees and such?

1. Don't assume that those criticizing C constructs are novice C
   programmers.  "The more I know C, the more I like my dog" ;-)

2. I would _hope_ that we are getting degrees in order to learn how to
   design systems, how to manage the development process, how to
   develop systems reliably, how to approach NP complete problems, how
   to test systems, how to avoid duplication of effort, how to estimate
   system size, etc.  Learning language/programming idioms shouldn't
   be very high on the list!

--
Bob Kitzberger	        +1 (916) 274-3075	        rlk@rational.com
Rational Software Corp., 10565 Brunswick Rd. #11, Grass Valley, CA 95945
     "Though the boys throw stones at frogs in sport, yet the frogs 
       do not die in sport but in earnest."      - Plutarch

Re: "Subtract C, add Ada"

[Matt Kennel]

Jay Martin (jmartin@oahu.cs.ucla.edu) wrote:
: Heh, (C Idiom == Idiotm)

: >Writing ``for (p = head; p; p = p->next) { /* process list */ }''

: Ptr := Head;
: while (Ptr /= null) loop
:   ...
:   Ptr := Ptr.Next;
: end loop;

: (My Ada is rusty, I only program in C++ now)

		"Think Globally, Act Locally."	

All these silly questions come down to the fact that control
structures are hardwired into the language, but not easily
reprogrammable.

Real iterations in real problems come in many forms.  You need a
user-progammable construction that goes straight to the problem.
C++ types 'iterators' are a good first step, but I don't feel
super comfortable with them.  What I think is even better is
Sather's "iters".  Instead of arguing over silly little details
of various Pascal or C control structures or whatever their trivial
variations, we should desire something much better and powerful among
all the inventions that have been occured over the last 20 years.

In particular I know about Sather's iters, which are practical
and convenient.

Example:
--------
list,list2:LIST{BLAH};
loop
  	list_element := list.elt!;  -- iterate through elements of "list".

	process(list_element);

	while!(list_element /= special_gonzo); 
                -- break out if we hit mr gonzo.

	list_element2 := list2.elt!;	
	  -- parallel (not nested) iteration through second list

	process2(list_element,list_element2);
end;


"elt!" is a feature in LIST{BLAH} which returns successive elements of
the list, and breaks out if it hits the end.

This fragment does exactly what it looks like it does.  And the
user of the "list" does not need to know whether it returns elements by
dint of following successive pointers, stepping through arrays, or black magic.

It eliminates stupid "off-by-one" errors and needless special boundary
cases.

cheers
Matt

--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".

Re: "Subtract C, add Ada"

[David Moore]

[somebody wrote]
>|> Personally, the lack of this sort of compactness in Ada, and things like
>|> pre- and post-increment/decrement are one of my minor gripes about the
>|> language. OK, its no big thing to write:
>|> 
>|>     P(I) := Q(I);
>|>     I := I + 1;
>|> 
>|> instead of
>|>  
>|>     *p++ = *q++;
>|> 
>|> but I actually *do* find the C representation easier/better etc. (perhaps
>|> I'm wierd?)

>Even if I like C, I think that this ++ is ugly and I'm glad that there isn't such
>a thing in Ada. On the other hand what do you think about the operators += *= ...
>They make thing shorter AND easier to read, a += 5; means exactly add 5 to a.
>So don't you think that these construct have their place in Ada.

The short circuit forms are kind of useful. On the other hand, what does
this do?

int j=0;
int f() {
	return j++;
	}
main () {
int a[10];

....

a[f()]+=1;

Is it the same or different to:   a[f()]=a[f()]+1;   ?

I believe f() gets called once. I would have to get out the standrd to be 100%
sure. 

It is also easy to write abominations like:

 -- search the table

 while (a[i++]!=b);

Whenever you use post-increment in a condition, you always have to stop and
wonder about your post-condition - I find it easier to always write the
loop out in full.


Shorthand forms can be like a bathtub containing two inches of water -
not enough to soak, but enough to drown. 

Re: "Subtract C, add Ada"

[R_Tim_Coslet]

>Samuel Mize (smize@Starbase.NeoSoft.COM) wrote:
>: Sure you do, if there was a programmer error, or a hardware glitch,
>: or a bad memory location, etc.  These are the things you don't want.
>: Given that you can't eliminate those, oh *boy* do you want exceptions,
>: given the alternative (core dump at 30,000 feet -- how do I reboot
>: my F-16?!?!?!?)
>
>However, for systems with the capability to degrade cleanly, exceptions are
>a very good thing and in fact are widely used in embedded avionics software.
>
>--------------------------------------------------------------------

The software I'm currently working on for a cockpit display system
was specificly designed to USE exceptions to gracefully degrade the
system functionality in the presence of serious hardware problems.

Each 16ms display frame consists of a series of calls to the various
CSCs controlling the sybsystems of the display. If no fatal hardware
problems occur it runs completely without exceptions. But in the
case of fatal hardware failures (e.g. inability to access a subsystem)
an exception is raised within that CSC, terminating any further
processing for that subsystem for that frame, letting the other CSCs
have the "extra" unused time. Thus the system will gracefully degrade,
mo matter how deep it had gotten into the CSC for a given subsystem
when the hardware died. No exception is ever allowed to propagate
outside of the top level CSC in which it occured to the main task.

The exception processing is a little expensive (about 1ms/exception),
but with several CSCs consuming 4 or 5ms in normal operation and the
overall time budget a bit tight, the exception usually saves time
making the remaining 3ms or more available to other CSCs immediately
in that frame when such a failure occurs.

Same thing with a serious programmer error that was not detected in
test: the affected CSC dies gracefully and the system functionality
degrades... BUT the REST of the system continues to function!

Such graceful degradation in function would have been MUCH harder
to implement in this system WITHOUT exceptions.

                                        R. Tim Coslet

Usenet: R_Tim_Coslet@cup.portal.com
        technology, n.  domesticated natural phenomena

Re: "Subtract C, add Ada"

[Samuel Mize]

In article <3frqpg$re5@cronkite.seas.gwu.edu>,
David O'Brien <dobrien@seas.gwu.edu> wrote:
...
>C was designed in the 70's. ...
>So, I think that "compilers *couldn't* optimize code" may be an over
>generalization.

My apologies for a loose statement.

I meant to address the observed beliefs of people who feel
that they can write more-efficient code in C.  Generally,
they hand-write code-level optimizations; they can see it,
so they believe in it.  They don't expect the compiler to
optimize much.  Some of them don't *want* the compiler to
optimize; they're using side effects and "slick tricks" to
save three instructions per hundred.  Of course, a good
optimizer would do far better for them, but they can't see that
unless they meter their program, optimize it, and meter it
again.  Why bother with what when they *know* that it's more
efficient code...

Of course, the source code doesn't run.  The object code runs.

...
>You are making a *major* assumption ...
>Again, you really are thinking with ...

Your entire post is right, except for attributing these beliefs
to *me*.  I was unclear.  These are beliefs that C programmers
have stated to me, as to why C is "more efficient" than Ada.
Of course, if a programmer is manually optimizing, he/she must
have assumptions about, and a model of, the machine on which
the code will run.  Sometimes, these will be wrong.

Another argument for machine optimization, which Ada better
supports.

>-- David O'Brien	(dobrien@sea.gwu.edu)

Yours in agreement,
Sam Mize - smize@starbase.neosoft.com

Re: "Subtract C, add Ada"

[Samuel Mize]

In article <1995Jan23.154631.6702@sei.cmu.edu>,
Robert Firth <firth@sei.cmu.edu> wrote:
>In article <3fo2ot$su2@miranda.gmrc.gecm.com> bill@valiant (R.A.L Williams) writes:
>
...
>> 1. It allows your code to be more compact.
>
>>    NB DONT confuse compactness with poor layout! I find that, for example:
>>
>>       while ((c = getchar()) == ' ')
>>       {
>>          /* count spaces */
>>       }
>>
>>    is clearer than the 'expanded' alternative (to *me* :-).
>
>Nope, I find this totally unclear.  Who's counting?  Unless I've missed
>an invisible declaration, initialisation, and increment, the above
>code *doesn't* count spaces, it skips them.

I think he intended the comment to represent elided code.

.. [good point about explicit exit condition not repeated]

>Note also that if there are *no more* non space characters, the C code
>dies in an infinite loop, while the Ada code automatically does the
>right thing, namely raises the END_ERROR exception.

Well "of course" we're assuming that there is no programmer error,
this is C!  ;-)

This bit of code is based on the assumption that there is a null at
the end of your string -- oh, but this is a file read.  C guys:
does C return a null if you getchar at EOF?  Or is this a misplaced
array idiom?

Of course, we *never* see strings without nulls in C...

Sam Mize - smize@starbase.neosoft.com

Re: "Subtract C, add Ada"

[N. Mellor]

In article <3fode9$dap@soleil.uvsq.fr> hebert@prism.uvsq.fr (Renaud HEBERT) writes:

>|> Personally, the lack of this sort of compactness in Ada, and things like
>|> pre- and post-increment/decrement are one of my minor gripes about the
>|> language. OK, its no big thing to write:
>|> 
>|>     P(I) := Q(I);
>|>     I := I + 1;
>|> 
>|> instead of
>|>  
>|>     *p++ = *q++;
>|> 
>|> but I actually *do* find the C representation easier/better etc. (perhaps
>|> I'm wierd?)

>Even if I like C, I think that this ++ is ugly and I'm glad that there isn't such
>a thing in Ada. On the other hand what do you think about the operators += *= ...
>They make thing shorter AND easier to read, a += 5; means exactly add 5 to a.
>So don't you think that these construct have their place in Ada.

This seems a valid point to me, particularly because += 
simplifies and clarifies expressions, particularly complex ones. I 
don't think there'd be much disagreement over this one, for example:

foo( bar( zot( element + 1))) = foo( bar(zot( element + 1))) + 1;

foo( bar( zot(element + 1))) += 1;

The second clearly saves on mistakes and makes the whole line more readable. 
To check the first, you need to do a mechanical, lexeme by lexeme comparison 
of the two array references to check that they're the same-- not a great score 
in the readability stakes. This is a clear example of C shorthand being 
superior, in some situations, in some respects, to Ada's straightforwardness. 
It isn't the whole story, of course.

BUT...self-referencing assignments are a very common idiom in just about any 
language, and it's only right that we should at least discuss ways of 
expressing them elegantly. Though on the whole C/C++ haven't seen me for dust, 
I do miss +=, -= and algebraic ifs (the ?: operator pair). All of these can 
usefully reduce complexity in very busy and convoluted bits of code.

Of course, there are other good reasons for not having these goodies. 
One is that they're not essential, and too many operators can increase the 
complexity of the language disastrously. One of the problems with C is its
plethora of operators and the consequent complexity of the operator precedence 
rules. Add to that C's blurring of the distinction between statements and 
expressions and you have serious readability problems, whether for novices or 
experts.

The bottom line is that it's simple to write an Ada procedure which safely 
adds or subtracts its second argument from its first, which can be defined as 
an in out parameter:

procedure self-add(in out var, in expression) is
  var := var + expression;
end self-add;

and use it as in

self-add( foo( bar( zot( element + 1))) , 1);


Any other thoughts?

Nick Mellor
Leeds

Re: "Subtract C, add Ada"

[Robert Dewar]

Oh no! don't say that we are going to have this thread deteriorate into
"look at this weird C code and tell me what it does". Surely there is
some other newsgroup where people are happier to play this game.

Incidentally, it is interesting that the typical Ada puzzler has the form:

 is this weird construct legal,

rather than

 what does this weird code do?

Of course I realize you can construct examples the other way round in both
cases, but still I think typically this is the pattern (compare for example
the C Puzzle book, with Exploring Ada)

This somewhat goes along with the general experience that it is harder to
get programs past an Ada compiler than past a C compiler, but once they
are past, they hav a better chance of behaving as expected!

Re: "Subtract C, add Ada"

[David O'Brien]

Robert Firth (firth@sei.cmu.edu) wrote:

: 	LOOP
: 	   get(c);
: 	   EXIT WHEN c /= ASCII.SP;
: 	END LOOP;

: Note also that if there are *no more* non space characters, the C code
: dies in an infinite loop, while the Ada code automatically does the
: right thing, namely raises the END_ERROR exception.

Woa!  Just how is it going to be determined that "enough" spaces have
been processed before it is decided that we have an infinate loop?
I'm not too sure I want some compiler/run-time to decide it has had
enough and kill my program...

-- David O'Brien	(dobrien@seas.gwu.edu)




: >OK, its no big thing to write:
: >
: >    P(I) := Q(I);
: >    I := I + 1;
: >
: >instead of
: > 
: >    *p++ = *q++;
: >
: >but I actually *do* find the C representation easier/better etc. (perhaps
: >I'm wierd?)

: Again, I don't see it.  The Ada code makes it clear that *corresponding*
: elements of the array Q are being copied into P - though, of course,
: a real Ada programmer (TM) would have written just P := Q.  The C code
: doesn't make that clear - you're going to have to ferret out the
: initialisations of p and q to determine that.  And if you worry about
: the correctness of the copy - for instance, whether P and Q are the
: same size - that's surely going to be a lot easier to establish in Ada.

Re: "Subtract C, add Ada"

[David O'Brien]

Samuel Mize (smize@Starbase.NeoSoft.COM) wrote:
: In article <1995Jan23.154631.6702@sei.cmu.edu>,
: Robert Firth <firth@sei.cmu.edu> wrote:
: >In article <3fo2ot$su2@miranda.gmrc.gecm.com> bill@valiant (R.A.L Williams) writes:
: >
: ...
: >> 1. It allows your code to be more compact.
: >
: >>    NB DONT confuse compactness with poor layout! I find that, for example:
: >>
: >>       while ((c = getchar()) == ' ')
: >>       {
: >>          /* count spaces */
: >>       }
: >>

: This bit of code is based on the assumption that there is a null at
: the end of your string -- oh, but this is a file read.  C guys:
: does C return a null if you getchar at EOF?  Or is this a misplaced
: array idiom?

This code is *not* based on the assumption that there is a ASCII NUL at the
end of the string.  There is nothing here that implies a string.  A
string being a series of characters terminated by an ASCII NUL
character.  Nor is this a file read.  getchar reads from the standard
input.  This would be interactive input unless the input has been
redirected to a file.

C (what I believe you are actually asking is does getchar return a NUL
at EOF), returns the EOF "character" at EOF.  If the above code was
reading from a file, the loop would terminate at EOF since EOF is not
the same value as a space character.  So the code fragment is still ok
with redirected input.

-- David O'Brien	(dobrien@seas.gwu.edu)

Re: "Subtract C, add Ada"

[Robb Nebbe]

In article <lawnm.33.00146988@leeds.ac.uk>, lawnm@leeds.ac.uk (N. Mellor) writes:
|> 
|> This seems a valid point to me, particularly because += 
|> simplifies and clarifies expressions, particularly complex ones. I 
|> don't think there'd be much disagreement over this one, for example:
|> 
|> foo( bar( zot( element + 1))) = foo( bar(zot( element + 1))) + 1;
|> 
|> foo( bar( zot(element + 1))) += 1;
|> 
|> The second clearly saves on mistakes and makes the whole line more readable. 
|> To check the first, you need to do a mechanical, lexeme by lexeme comparison 
|> of the two array references to check that they're the same-- not a great score 
|> in the readability stakes. This is a clear example of C shorthand being 
|> superior, in some situations, in some respects, to Ada's straightforwardness. 
|> It isn't the whole story, of course.

For problems like this I would rename the foo term:

  declare
    Following_Element : Integer renames foo( bar( zot( element + 1 )));
  begin
    if Following_Element < Limit then
      Following_Element := Following_Element + 1;
    else
      Following_Element := Following_Element + 10;
    end if;
  end;

I don't really see the benefit of operators like += in a language.

As an aside to no one in particular if you find you have lots of
complicated terms like this in your code you should take it as a
hint that there might be a problem with the design.

Robb Nebbe

Re: "Subtract C, add Ada"

[Robert A Duff]

In article <3g32li$5jd@Starbase.NeoSoft.COM>,
Samuel Mize <smize@Starbase.NeoSoft.COM> wrote:
>This bit of code is based on the assumption that there is a null at
>the end of your string -- oh, but this is a file read.  C guys:
>does C return a null if you getchar at EOF?  Or is this a misplaced
>array idiom?

I believe getchar returns -1 at eof.

- Bob

Re: "Subtract C, add Ada"

[John Volan]

lawnm@leeds.ac.uk (N. Mellor) writes:

>This seems a valid point to me, particularly because += 
>simplifies and clarifies expressions, particularly complex ones. I 
>don't think there'd be much disagreement over this one, for example:
>
>foo( bar( zot( element + 1))) = foo( bar(zot( element + 1))) + 1;
>
>foo( bar( zot(element + 1))) += 1;
>
>The second clearly saves on mistakes and makes the whole line more readable. 
>To check the first, you need to do a mechanical, lexeme by lexeme comparison 
>of the two array references to check that they're the same-- not a great score 
>in the readability stakes. This is a clear example of C shorthand being 
>superior, in some situations, in some respects, to Ada's straightforwardness. 
>It isn't the whole story, of course.


Of course it isn't.  One way of tackling this kind of situation
without introducing new operators into the language is to exploit
renaming declarations:

	declare
	  Foobarzot : Whatever_Type renames Foo(Bar(Zot(Element+1)));
	begin
	  Foobarzot := Foobarzot + 1;
	end;

"Foobarzot" thus becomes a convenient local temporary alias for the
object otherwise known by the more cumbersome name of
"Foo(Bar(Zot(Element+1)))".  This makes the incrementing assignment
just as easy to read as any C-like alternative.  It also makes it clear
that the same object is being referenced on both sides of the
assignment, without needing to duplicate "Foo(Bar(Zot(Element+1)))"
(which is obviously error-prone).  Additionally, it makes it clear that
the computations that occur in "Foo(Bar(Zot(Element+1)))" should happen
only once, before incrementing the resulting object.

>BUT...self-referencing assignments are a very common idiom in just about any 
>language, and it's only right that we should at least discuss ways of 
>expressing them elegantly. Though on the whole C/C++ haven't seen me for dust, 
>I do miss +=, -= and algebraic ifs (the ?: operator pair). All of these can 
>usefully reduce complexity in very busy and convoluted bits of code.
>
>Of course, there are other good reasons for not having these goodies. 
>One is that they're not essential, and too many operators can increase the 
>complexity of the language disastrously. One of the problems with C is its
>plethora of operators and the consequent complexity of the operator precedence 
>rules. Add to that C's blurring of the distinction between statements and 
>expressions and you have serious readability problems, whether for novices or 
>experts.


I couldn't aggree with you more.


>The bottom line is that it's simple to write an Ada procedure which safely 
>adds or subtracts its second argument from its first, which can be defined as 
>an in out parameter:
>
>procedure self-add(in out var, in expression) is
>  var := var + expression;
>end self-add;
>
>and use it as in
>
>self-add( foo( bar( zot( element + 1))) , 1);


Er, properly speaking, this should be something like:

    procedure Add (To : in out Whatever_Type; Addend : in Whatever_Type) is
    begin
      To := To + Addend;
    end Add;

And then it could be used as in:

    Add (To => Foo(Bar(Zot(Element+1))), Addend => 1);

In fact, the declare-block I wrote above could be viewed as an "inline"
equivalent to this procedure call.


>Any other thoughts?
>
>Nick Mellor
>Leeds


Hope this helps.

					-- John Volan

--------------------------------------------------------------------------------
 Me : Person :=
   (Name => "John G. Volan",  E_Mail_Address => "jgv@swl.msd.ray.com",
    Employer => "Raytheon",   Affiliation => "Enthusiastic member of Team-Ada!",
    Shameless_Controversial_Marketing_Slogan_For_Favorite_Language =>
      "<<<< Ada95: The World's *FIRST* Internationally-Standardized OOPL >>>>",
    Humorous_Language_Lawyerly_Disclaimer =>
      "These opinions are undefined by my employer, so using them would be "  &
      "totally erroneous ... or would that be a bounded error? :-) ");
--------------------------------------------------------------------------------

Re: "Subtract C, add Ada"

[Norman H. Cohen]

|> Real iterations in real problems come in many forms.  You need a
|> user-progammable construction that goes straight to the problem.
|> C++ types 'iterators' are a good first step, but I don't feel
|> super comfortable with them.  What I think is even better is
|> Sather's "iters".  Instead of arguing over silly little details
|> of various Pascal or C control structures or whatever their trivial
|> variations, we should desire something much better and powerful among
|> all the inventions that have been occured over the last 20 years.

I think CLU, circa 1979, still holds the prize for the best iteration
abstraction.  When defining a CLU abstract data type that represents some
sort of collection, you can define one or more iterators among its
operations.  An iterator is like a procedure declared to take a value of
the collection type as a parameter and to "yield" values of some element
type.  The iterator is executed as a coroutine during the execution of
the loop.  Values that are yielded by the iterator become the values of
the loop parameter on successive iterations of the loop.

My CLU syntax is rusty, but if you have the equivalent of a private type
for doubly linked lists, you could define the following iterators for it: 

   elements =
      iter(l: list_type) yields (element_type)
         next: cell_type = l;
         while next.forward_link ~= l do
            yield(next.item)
         end
      end

   reverse_elements =
      iter(l: list_type) yields (element_type)
         next: cell_type = l;
         while next.backward_link ~= l do
            yield(next.item)
         end
      end

Then you could iterate over the private type as follows: 

   for item in elements(my_list) do
      ...
   end

   for item in reverse_elements(my_list) do
      ...
   end

Iterators could even be recursive: 

   preorder_traversal =
      iter(t: tree_type) yields node_info_type
         yield(t.node_info);
         for ni in preorder_traversal(t.left_subtree) do
            yield(ni)
         end
         for ni in preorder_traversal(t.right_subtree) do
            yield(ni)
         end
      end

(Breaking out of a loop terminates the iterator.  Since CLU supported
exceptions, I think it would have been better for the next yield
statement to have raised an exception inside the iterator, thus giving
the iterator the opportunity to perform cleanup actions.)

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: "Subtract C, add Ada"

[Charles H. Sampson]

In article <3fvqj5$ofr@miranda.gmrc.gecm.com>,
R.A.L Williams <bill@valiant> wrote:
>In article <3feevh$615@gnat.cs.nyu.edu> Robert Dewar wrote:
>: ... there are lots of things that Ada people take for granted that cannot
>: be checked in C, there just isn't enough information. C has no separation
>: of scalar types, no ranges on scalar types, and the ubquitous use of
>: pointers, and their similarity to arrays means that sophisticated aliasing
>: analysis is required to even approximate the type checking that occurs
>: in the context of access types in Ada. There are many other examples.
>
>Ranges - no, but my Microsoft C compiler certainly *does* warn me when I
> - mix signed and unsigned integers (of course, Ada83 doesn't have unsigned)
> - assign the result of 'long' expressions to shorts or chars etc.
> - perform 'unchecked conversion' between integers and pointers

     What is it warning you about?  All three of these are reasonable
things to do (o. k., the third is a little shady), so is getting a warn-
ing from the compiler about them really beneficial.  Typically, a pro-
liferation of such noisy warnings can cause the programmer to overlook
an important compiler message.

     I'm not sure what you mean by "mixing" signed and unsigned integers,
but if they come from the same base type, why shouldn't they be "mixed"?
They are just integers, after all.  If you mean assigning a value from a
signed (sub)type to an object of an unsigned (sub)type, then Ada will warn
you about it, by means of an exception, when you do it wrong but will be
silent as long as you do it right.

     The same thing will happen if you assign a value from a (sub)type
having a big range to an object of a (sub)type having a smaller range, or
to an object of type Character (after you've done all the necessary ex-
plicit conversions).

     Finally, if you want to perform an unchecked conversion from integer
to pointer, or vice versa, in Ada you have to use a syntax that basically
tells the compiler that you know what you're doing.  I don't know about
you, but I sure wouldn't look very kindly on a compiler that warns me in
such a case that I might not know what I'm doing.

Re: "Subtract C, add Ada"

[Dr. Richard Botting]

Norman H. Cohen (ncohen@watson.ibm.com) wrote:
: |> Real iterations in real problems come in many forms.  You need a
: |> user-progammable construction that goes straight to the problem.
: |> C++ types 'iterators' are a good first step, but I don't feel
: |> super comfortable with them.  What I think is even better is
: |> Sather's "iters".  Instead of arguing over silly little details
: |> of various Pascal or C control structures or whatever their trivial
: |> variations, we should desire something much better and powerful among
: |> all the inventions that have been occured over the last 20 years.

: I think CLU, circa 1979, still holds the prize for the best iteration
: abstraction.  

Well I just have to point out that iterators in Ada date back to January
1983 - "Studies in Ada Style" 2nd Eddition, By 
	Hibbard,Hisgen,Rosenberg,shaw,sherman, Pub Springer Verlag.....

Also: I agree that programming language loops are a special and
restricted kind of itterator (in some sense or other),
But, for me, iterators are a speical and restrictive case of
a cooperating sequential processes... as are Ada Tasks, UNIX/C pipes,
JSP inverted code/semin-co-routines, etc.  (Yes, I have seen the C++
co-routine class library, :-( )

It would be so nice to write code like this
	int next(void)
	{
		....
		release(c);
		.....
		release(d);
		...
		if(something)
			release(x);
		...
		while(somcond){
			release(c);
			make_next(&c);
		}

		release(EOF);
	}
And, whenever you called 'next(...)' it finds/computes/fudges up the
next char until your get the the end and it pops out the EOF....

This is easy to fake, but I would like it in my languages.

The word RELEASE is from the COBOL sorting.... so why can't 
C++ keep up with COBOL?

:-)}

--
EMail: dick@csci.csusb.edu=rbotting@wiley.csusb.edu.
ftp://ftp.csci.csusb.edu/dick
<a href="http://www.csci.csusb.edu/dick/">WWW</a>
Disclaimer::=`CSUSB may or may not agree with this message`.
Copyright(1995)::=`Copy as long as you include this copyright and signature`.

Re: "Subtract C, add Ada"

[Samuel Mize]

The attached discussion of "self-referencing assignments" (I like
the term -- is it a standard term?) raises some points for me.

Yes, there should be a clearer method for self-referencing
assignments.  The usual argument (that I've seen) for the 
C operators +=, *=, etc., is that the code won't have to do
the same dereference/index/etc. series twice.  This is dumb;
this is what the optimizer should do.  BUT your point about
readability is very true.  The action "modify this value
somehow" is a common task.

Of course, the C operators are prone to typos.

Also, you can only do a simple calculation (one multiply,
one add...).

It seems to me that something more general would be useful,
along the lines (NOT THIS SYNTAX, THIS IDEA):

     foo( bar( zot( element + 1))) := <left> * ( <left> + 3 );

Question for the net: how much were self-referencing assignment
operators, and and algebraic ifs (the ?: operator pair) considered
for Ada83 and Ada95 (1).  Are they discussed in the Rationales,
or where would I find discussion of the reason for their omission
from Ada?  (I'll be looking through the Rationales for this, but
if you know where to look it will help me.)

Samuel Mize - smize@starbase.neosoft.com

(1) YES!  THAT'S RIGHT!  NINETY-*FIVE*!  I GOT THE RIGHT NUMBER THIS
    TIME, OK?      :-)      =8-p

In article <lawnm.33.00146988@leeds.ac.uk>,
N. Mellor <lawnm@leeds.ac.uk> wrote:
>In article <3fode9$dap@soleil.uvsq.fr> hebert@prism.uvsq.fr (Renaud HEBERT) writes:
...
>>... On the other hand what do you think about the operators += *= ...
>>They make thing shorter AND easier to read, a += 5; means exactly add 5 to a.
>>So don't you think that these construct have their place in Ada.
>
>This seems a valid point to me, particularly because += 
>simplifies and clarifies expressions, particularly complex ones. I 
>don't think there'd be much disagreement over this one, for example:
>
>foo( bar( zot( element + 1))) = foo( bar(zot( element + 1))) + 1;
>
>foo( bar( zot(element + 1))) += 1;
>
>The second clearly saves on mistakes and makes the whole line more readable. 
>To check the first, you need to do a mechanical, lexeme by lexeme comparison 
>of the two array references to check that they're the same-- not a great score 
>in the readability stakes. This is a clear example of C shorthand being 
>superior, in some situations, in some respects, to Ada's straightforwardness. 
>It isn't the whole story, of course.
>
>BUT...self-referencing assignments are a very common idiom in just about any 
>language, and it's only right that we should at least discuss ways of 
>expressing them elegantly. Though on the whole C/C++ haven't seen me for dust, 
>I do miss +=, -= and algebraic ifs (the ?: operator pair). All of these can 
>usefully reduce complexity in very busy and convoluted bits of code.
>
>Of course, there are other good reasons for not having these goodies. 
>One is that they're not essential, and too many operators can increase the 
>complexity of the language disastrously. One of the problems with C is its
>plethora of operators and the consequent complexity of the operator precedence 
>rules. Add to that C's blurring of the distinction between statements and 
>expressions and you have serious readability problems, whether for novices or 
>experts.
>
>The bottom line is that it's simple to write an Ada procedure which safely 
>adds or subtracts its second argument from its first, which can be defined as 
>an in out parameter:
>
>procedure self-add(in out var, in expression) is
>  var := var + expression;
>end self-add;
>
>and use it as in
>
>self-add( foo( bar( zot( element + 1))) , 1);
>
>
>Any other thoughts?
>
>Nick Mellor
>Leeds

Re: "Subtract C, add Ada"

[Anders Juul Munch]

ncohen@watson.ibm.com (Norman H. Cohen) writes:

>I think CLU, circa 1979, still holds the prize for the best iteration
>abstraction.  When defining a CLU abstract data type that represents some
>sort of collection, you can define one or more iterators among its
>operations.  An iterator is like a procedure declared to take a value of
>the collection type as a parameter and to "yield" values of some element
>type.  The iterator is executed as a coroutine during the execution of
>the loop.  Values that are yielded by the iterator become the values of
>the loop parameter on successive iterations of the loop.

>My CLU syntax is rusty, but if you have the equivalent of a private type
>for doubly linked lists, you could define the following iterators for it: 

>   elements =
>      iter(l: list_type) yields (element_type)
>         next: cell_type = l;
>         while next.forward_link ~= l do
>            yield(next.item)
>         end
>      end

>Then you could iterate over the private type as follows: 

>   for item in elements(my_list) do
>      ...
>   end

>[lotsa stuff omitted]


Very nice.  But how about the kind of parallel iteration over two lists, 
that other posters showed for Sather and ICON.  Can you do that in CLU also?


-Anders Munch, juul@diku.dk
Still confused but at a higher level

Re: "Subtract C, add Ada"

[Mark A Biggar]

In article <3g7ame$5d8@Starbase.NeoSoft.COM> smize@Starbase.NeoSoft.COM (Samuel Mize) writes:
>It seems to me that something more general would be useful,
>along the lines (NOT THIS SYNTAX, THIS IDEA):
>
>     foo( bar( zot( element + 1))) := <left> * ( <left> + 3 );

That's what rename is for and it's more powerful to boot as you can choose
exactly what parts of your expression get short names, For example:

declare
	Left: Interger renames foo(bar(zot(element+1)));
begin
	Left := Left * (Left + 3);
end;

but also:

declare
	Index: Integer renames bar(zot(element+1));
begin
	foo(Index) := foo(Index) * ( foo(Index) + 3);
end;

You may well want to use the second case, if that documents your algorithm
better.  Note that a good compiler probably produces identical code for
both examples assuming good common expression elimination.

--
Mark Biggar
mab@wdl.loral.com

Re: "Subtract C, add Ada"

[Jules]

In article <3g1shu$ksc@rational.rational.com>,
	davidm@rational.com (David Moore) writes:

>It is also easy to write abominations like:
>
> -- search the table
>
> while (a[i++]!=b);
>
>Whenever you use post-increment in a condition, you always have to stop and
>wonder about your post-condition - I find it easier to always write the
>loop out in full.

It is also easy to write stupid code like this when NOT using shorthand code
like this.

Of course the correct version (and the version I still prefer) is:

while (a[i++]!=b && i < ARRAYLIMIT);

-- 
/* Julian R Hall				csusb@csv.warwick.ac.uk
   
   Flames should be redirected to /dev/null - I don't know what
   I'm saying myself so don't expect it to make sense all the time!         */

Increment operator (+=)

[Jacob Sparre Andersen]

Robert Dewar (dewar@cs.nyu.edu) wrote the most recent article I have read 
in the thread about the operator "+=" in C.

In two still not mentioned languages (dialects) there are these solutions 
to the 'problem':

In COMAL (BASIC like) there are ":+" and ":-" incrementing and decrementing 
'assignments'.

    antal_sider:+1
    rest:-1

In Borland's Pascal dialect the system library contains these procedures:

    Inc(var SomeInteger : <integer type> ; Step : <integer type>) ;
    Dec(var SomeInteger : <integer type> ; Step : <integer type>) ;

I think the last solution is the right way to do it in Ada. But it's only 
really usefull, if any type with "+" and "-" operators can 'inherit' the 
procedures (I don't think that's how Ada 95 works).
The Borland way (tm :-) is just how we should code. No Ada 96 :-)

--

I like the idea about using local renames.

--

"add 1 to long-complex-name" - What a nice readable piece of code. What's 
wrong with this language? :-)

Regards,
                Jacob Sparre Andersen
--
A good movie? - What about three? - Kieslowskis 'White', 'Blue' and 'Red'!
--
URL's: "mailto:sparre@nbi.dk", "http://meyer.fys.ku.dk/~sparre", 
       "mailto:sparre+@pitt.edu" & "http://www.pitt.edu/~sparre".
--
"We need a plan to diverge from", Fesser

Re: "Subtract C, add Ada"

[David O'Brien]

Samuel Mize (smize@Starbase.NeoSoft.COM) wrote:
: In article <3g4p94$g07@cronkite.seas.gwu.edu>,
: David O'Brien <dobrien@seas.gwu.edu> wrote:
: >Robert Firth (firth@sei.cmu.edu) wrote:
: >
: >: 	LOOP
: >: 	   get(c);
: >: 	   EXIT WHEN c /= ASCII.SP;
: >: 	END LOOP;
: >
: >: Note also that if there are *no more* non space characters, the C code
: >: dies in an infinite loop, while the Ada code automatically does the
: >: right thing, namely raises the END_ERROR exception.
: >

: If this is scanning a string that has no more spaces, Ada will
: raise an exception at the end of the string.  C will scan merrily
: off the end of the array and through the memory following until it
: hits a space or you get "segmentation error (core dumped)".

Boy are we making assumptions about the processing that follows counting
the number of spaces.  Would you care to explain how C will core dump?

The loop will stop when there are no more spaces IN A ROW.  The original
C code was:
	while ( (c = getchar()) == ' ' ) { /* count spaces */ }

The Ada code and the C code ARE THE SAME.  That being, both count the
number of spaces in a sequence.  Once the first non-space character is
read (could be A thru Z, EOF, ASCII NUL, what ever), both of these code
fragments will exit the while loop.  There is nothing in these code
fragments that may be used to complain about C's handling of strings.
Code layout and where expressions may be used is what this thread was
about.

If you really want to get into it, the Ada way is worse.  If the input
string contained only spaces, Ada would exception when EOF was hit.
C on the other hand would exit the loop cleanly and what ever came next
would execute.  In Ada I hope you wrapped the while loop with an
exception handler.

-- David O'Brien	(dobrien@seas.gwu.edu)

Re: "Subtract C, add Ada"

[Matt Kennel]

Jules (csusb@csv.warwick.ac.uk) wrote:
: In article <3g1shu$ksc@rational.rational.com>,
: 	davidm@rational.com (David Moore) writes:

: >It is also easy to write abominations like:
: >
: > -- search the table
: >
: > while (a[i++]!=b);
: >
: >Whenever you use post-increment in a condition, you always have to stop and
: >wonder about your post-condition - I find it easier to always write the
: >loop out in full.

: It is also easy to write stupid code like this when NOT using shorthand code
: like this.

: Of course the correct version (and the version I still prefer) is:

: while (a[i++]!=b && i < ARRAYLIMIT);

Better yet is to have a smart loop abstraction.  For example:

loop
   e := a.elt!; -- automagically step through elements of a.
   if (e = b) then break! end;
   -- otherwise do stuff here.
end;

Now isn't that what you really meant to say before?

--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".

Re: Adding in COBOL...

[Robert Dewar]

David Weller says:  

Easy, Robert:

        add (1, to=> long_complex_name);

Gee, I thought I'd never see the day I could teach Robert something

Umm? I think you forgot something David, what is the type of the add
procedure. I guess it is a generic, so don't forget to instantiate it,
and oh yes, remember to pass the "+" operator to the generic while you
are at it (wouldn't want the dread reemergence doing us in), and also
remember to inline it (and hope that inlining generic instances works
fine and ....

Re: "Subtract C, add Ada"

[Mark S. Hathaway]

> In article <3g4p94$g07@cronkite.seas.gwu.edu>,
> dobrien@seas.gwu.edu (David O'Brien) writes:

> : Robert Firth (firth@sei.cmu.edu) wrote:

> : 	LOOP
> : 	   get(c);
> : 	   EXIT WHEN c /= ASCII.SP;
> : 	END LOOP;
> :
> : Note also that if there are *no more* non space characters, the C code
> : dies in an infinite loop, while the Ada code automatically does the
> : right thing, namely raises the END_ERROR exception.

> Woa!  Just how is it going to be determined that "enough" spaces have
> been processed before it is decided that we have an infinate loop?
> I'm not too sure I want some compiler/run-time to decide it has had
> enough and kill my program...
> 
> -- David O'Brien	(dobrien@seas.gwu.edu)


Why should C code die in an infinite loop?  Wouldn't that eventually be
an end-of-file character, if not some other non-space character(s)?


Mark S. Hathaway       <hathawa2@marshall.edu>

Re: "Subtract C, add Ada"

[Michael Feldman]

In article <3gdro9$aud@spam.csv.warwick.ac.uk>,
Jules <csusb@csv.warwick.ac.uk> wrote:

>Of course the correct version (and the version I still prefer) is:
>
>while (a[i++]!=b && i < ARRAYLIMIT);

Hmmm - I think I learned somewhere that the && is short-circuit in C.
So wouldn't you want to switch the two conditions, i.e. check the
limit _before_ incrementing that index? (It's late at night; this
comment may be off the wall.)

Mike Feldman

Ada vs. C

[Martijn Bak]

>It all falls out of the design of the language. Constructs like "+="
>provide no benifit other than to save typing within a single
>statement. Take the statement:
>
>  Principle = Principle + (Interest * Time)
>
>The "+=" operator is MADE for this statement, but its ONLY benifit is
>to save me 11 characters in my source file. 

Nope, in general this is _not_ true! The statements
	expr1 += expr2;
and
	expr1 = expr1 + expr2;
are _not_ the same. In the former, expr1 is evaluated only once, in the
latter expr1 is evaluated twice. This is not only a matter of execution
speed. It is especially important if expr1 has side-effects.

There is also a conceptual benefit for the += (if expr1 is very complex).
Compare
	a[i->j(q,b)] = a[i->j(q,b)] + 2;
and
	a[i->j(q,b)] += 2;

In the latter case, neither the writer nor the reader of this code need
to check whether a[i->j(q,b)] and a[i->j(q,b)] realy are the same.

Yep, I _am_ a C programmer.

-- 
-- Martijn Bak -- AND Software -- Westersingel 108, 3015 LD  Rotterdam --
-- tel: +31-10-4367100 -- fax: +31-10-4367110 -- email: martijn@and.nl --

Re: "Subtract C, add Ada"

[Jay Martin]

First there was:
  Newtons Principia....
then came:
  Einstein's Theory of Relativity...
And Now....
  G E T C H A R ()!!!  BOM-BOM BOM-BOM BOM-BOM...
---------------------------------

For some laughs lets look at the man page for getchar():

NAME
     getc, getchar, fgetc, getw - get character or  integer  from
     stream

SYNOPSIS
     #include <stdio.h>

     int getc(stream)
     FILE *stream;

     int getchar()

     int fgetc(stream)
     FILE *stream;

     int getw(stream)
     FILE *stream;

DESCRIPTION
     getc() returns the next character (that is, byte)  from  the
     named  input  stream, as an integer.  It also moves the file
     pointer,  if  defined,  ahead  one  character   in   stream.
     getchar()  is  defined as getc(stdin).  getc() and getchar()
     are macros.

>> Hee Hee, are we getting a char or an "int"?  Well it returns
>> an int and then we need to do an implicit conversion back into
>> a char.  Assuming c is a char in "c = getchar()" then we have
>> just lost the ability to check for EOF since we may have read
>> a char with value 255 (assuming EOF = -1).  Implicit conversions
>> rule!!! 

     fgetc() behaves like getc(), but is a function rather than a
     macro.   fgetc()  runs more slowly than getc(), but it takes
     less space per invocation and its name can be passed  as  an
     argument to a function.

> Macros, ZOOOOOOOM!!!!!!

     getw() returns the next C int (word) from  the  named  input
     stream.   getw()  increments the associated file pointer, if
     defined, to point to the next word.  The size of a  word  is
     the  size  of an integer and varies from machine to machine.
     getw() assumes no special alignment in the file.

RETURN VALUES
     On success, getc(), getchar() and fgetc()  return  the  next
     character  from  the  named  input stream as an integer.  On
     failure, or on EOF, they return EOF. The  EOF  condition  is
     remembered,  even  on  a terminal, and all subsequent opera-
     tions which attempt to read from the stream will return  EOF
     until   the   condition  is  cleared  with  clearerr()  (see
     ferror(3V)).

>> Hey, maybe we could use this ferror() thingy to tell the difference
>> between EOF and char 255.  Well we probably should anyway to detect
>> the difference between EOF and failure. Oh, the elegance of it all!

     getw() returns the next C int from the named input stream on
     success.   On  failure, or on EOF, it returns EOF, but since
     EOF is a valid integer,  use  ferror(3V)  to  detect  getw()
     errors.

>> Oops! Sorry about that. 

SYSTEM V RETURN VALUES

     On failure, or on EOF, these functions return EOF.  The  EOF
     condition is remembered, even on a terminal, however, opera-
     tions which attempt to read from the stream will ignore  the
     current state of the EOF indication and attempt to read from
     the file descriptor associated with the stream.

>> Don't want to restrict the programmer!  Damn the torpedos!  Full
>> steam ahead!  Lets here it for SYSTEM V!!

SEE ALSO
     ferror(3V),  fopen(3V),   fread(3S),   gets(3S),   putc(3S),
     scanf(3V), ungetc(3S)

WARNINGS
     If the integer  value  returned  by  getc(),  getchar(),  or
     fgetc()  is  stored  into a character variable and then com-
     pared against the integer constant EOF, the  comparison  may
     never  succeed,  because  sign-extension  of  a character on
     widening to integer is machine-dependent.

BUGS
     Because it is implemented as a macro, getc() treats a stream
     argument  with  side  effects  incorrectly.   In particular,
     getc(*f++) does not work sensibly.  fgetc() should  be  used
     instead.

     Because of possible differences in word length and byte ord-
     ering, files written using putw() are machine-dependent, and
     may not be readable using getw() on a different processor.

>> We don't need these stinking warnings, they are obvious from the
>> include file!

------------------------------------------------------------------

Well this is what happens when you let incompetent pinheads
design operating system and languages.  Of course the clowns
in industry and academia standing around drooling at this shit
with the look of adoration on their faces doesn't help either.

I think I'll go punch a brick wall until my hands bleed.

Jay

"Subtract C, add Ada"

[R.A.L Williams]

In article <1995Jan23.154631.6702@sei.cmu.edu> you wrote:
: In article <3fo2ot$su2@miranda.gmrc.gecm.com> bill@valiant (R.A.L Williams) writes:

: I guess I'm about to show my ignorance of C, but I'm very confused
: bt this post.

: > 1. It allows your code to be more compact.

: >    NB DONT confuse compactness with poor layout! I find that, for example:
: >
: >       while ((c = getchar()) == ' ')
: >       {
: >          /* count spaces */
: >       }
: >
: >    is clearer than the 'expanded' alternative (to *me* :-).

: Nope, I find this totally unclear.  Who's counting?  Unless I've missed
: an invisible declaration, initialisation, and increment, the above
: code *doesn't* count spaces, it skips them.  And if that is its
: purpose, what's the point of the variable 'c'?  Why not just say

OK, I'm sorry, I didn't think I needed to spell things out in gratuitous
detail, so I just indicated the position and sort of code that might be
used by a comment. I haven't shown code that replaces spaces in an output
stream with text from the Koran either, sorry!

: Note also that if there are *no more* non space characters, the C code
: dies in an infinite loop, while the Ada code automatically does the
: right thing, namely raises the END_ERROR exception.

I'm afraid you *are* showing your ignorance of C. On each iteration of the
loop if the next input character is not a space (and this includes EOF)
then the loop terminates cleanly.

: >[example deleted]

: Again, I don't see it.  The Ada code makes it clear that *corresponding*
: elements of the array Q are being copied into P - though, of course,
: a real Ada programmer (TM) would have written just P := Q.  The C code
: doesn't make that clear - you're going to have to ferret out the
: initialisations of p and q to determine that.  And if you worry about
: the correctness of the copy - for instance, whether P and Q are the
: same size - that's surely going to be a lot easier to establish in Ada.

Again, a simplified example to illustrate a principle. The point is that
the less I have to move my eyes, or flip over pages, when reading/reviewing 
code, the more likely I am to understand it and find any bugs. You're
quite right, P := Q is an event more compact representation and I approve
(the Bill Williams official statement of approval!).

Bill Williams

Re: "Subtract C, add Ada"

[Samuel Mize]

Some of my earlier postings were not as clear as they should
have been.  Let me clarify.

In article <3gebnq$7f3@cronkite.seas.gwu.edu>,
David O'Brien <dobrien@seas.gwu.edu> wrote:
>Samuel Mize (smize@Starbase.NeoSoft.COM) wrote:
>: In article <3g4p94$g07@cronkite.seas.gwu.edu>,
>: David O'Brien <dobrien@seas.gwu.edu> wrote:
>: >Robert Firth (firth@sei.cmu.edu) wrote:
>: >
>: >: 	LOOP
>: >: 	   get(c);
>: >: 	   EXIT WHEN c /= ASCII.SP;
>: >: 	END LOOP;
>: >
>: >: Note also that if there are *no more* non space characters, the C code
>: >: dies in an infinite loop, while the Ada code automatically does the
>: >: right thing, namely raises the END_ERROR exception.
>: >

[discussion in Mize post of reading from a file deleted]

>: If this is scanning a string that has no more spaces, Ada will
>: raise an exception at the end of the string.  C will scan merrily
>: off the end of the array and through the memory following until it
>: hits a space or you get "segmentation error (core dumped)".
>
>Boy are we making assumptions about the processing that follows counting
>the number of spaces.  Would you care to explain how C will core dump?

I meant, if the NUL at the end of a string was clobbered,
or the array pointer was corrupted, and you started scanning
the wrong part of memory.  That isn't what I said, but is what
I meant.  I didn't clearly state that I was changing subject
somewhat, and I also got the logic of the test backward.  Sorry.

If the end-marker of a string is missing, or the array pointer
is corrupted, you can core dump right here.  No further
processing needed.

>
>The loop will stop when there are no more spaces IN A ROW.  The original
>C code was:
>	while ( (c = getchar()) == ' ' ) { /* count spaces */ }
>
>The Ada code and the C code ARE THE SAME.  That being, both count the

They aren't the same code lexically or logically. They ARE not THE SAME.
Someone else said that the C would go into an infinite loop, and that
this was the equivalent Ada code.  They were wrong.

The logically equivalent Ada (using text_io) would be

    while not end_of_file loop
        get (c);
        exit when c /= ' ';
    end loop;

>number of spaces in a sequence.  Once the first non-space character is
>read (could be A thru Z, EOF, ASCII NUL, what ever), both of these code
>fragments will exit the while loop.  There is nothing in these code
>fragments that may be used to complain about C's handling of strings.
>Code layout and where expressions may be used is what this thread was
>about.
>
>If you really want to get into it, the Ada way is worse.  If the input
>string contained only spaces, Ada would exception when EOF was hit.
>C on the other hand would exit the loop cleanly and what ever came next
>would execute.  In Ada I hope you wrapped the while loop with an
>exception handler.

No, you just have to understand how EOF is handled in both languages,
and write the Ada correctly.  This was not your error originally,
and since you're taking the pro-C side I won't dis you for not
recognizing an Ada error.  :-)

The C code is more terse, but not necessarily more efficient; that
depends on your compiler.  The C getc is probably checking for EOF
behind your back, instead of it being explicitly coded in.

I am now switching topics back to strings.  Someone in the thread 
brought up C going into an infinite loop.  I thought that person
may be confusing a file read with a string scan.  (Yes, it *is*
a file read; standard input is a file, as are standard output and
standard error.)

Anyway, on a string, you would ward the loop with a range check,
probably using a "for" clause:

     for I in String'range loop
         exit when String(i) = ' ';
     end loop;

or, if not starting at the start of the string:

     for I in Current_Pos .. String'last loop
         if String (I) = ' ' then
             Current_Pos := I;
             exit;
         end if;
     end loop;

In C, with a string, most programmers would just look for a
non-blank, including the NUL that is "always" at the end of
a string.  You can also explicitly code in a limit, as shown
by a previous poster in this thread (I don't have it handy).

In Ada, if you screw up and don't check the range, you can
get an exception.  In C, if you don't check the range, most
people don't consider it an error, but if the data gets
screwed up (no NUL or bad pointer) you can core dump.

To bring this back to code layout:  Ada provides a way to
check the range as part of the loop construct, and a
lexically-scoped way to handle the error case.  In C, you
*can* check for a bad array index but usually don't, and
have no way to check whether the array pointer has been
rewritten.  You have to register a signal handler to deal
gracefully with error cases.

>
>-- David O'Brien	(dobrien@seas.gwu.edu)

Re: "Subtract C, add Ada"

[David O'Brien]

Michael Feldman (mfeldman@seas.gwu.edu) wrote:
: In article <3gdro9$aud@spam.csv.warwick.ac.uk>,
: Jules <csusb@csv.warwick.ac.uk> wrote:

: >Of course the correct version (and the version I still prefer) is:
: >
: >while (a[i++]!=b && i < ARRAYLIMIT);

: Hmmm - I think I learned somewhere that the && is short-circuit in C.
: So wouldn't you want to switch the two conditions, i.e. check the
: limit _before_ incrementing that index? (It's late at night; this
: comment may be off the wall.)

Switching is required, and it would use the short-circuit idiom we love
so much in C.  But, the reason is that you skip that last element.  Say
we have:

	#define ARRAYLIMIT 3
	foo a[ ARRAYLIMIT ];

When i == 2, the access ``a[ i++ ] != b'' is ok.  However when we get to
``i < ARRAYLIMIT'', i == 3, and thus the statement is false and you stop
the loop for the wrong reason.  ``i <= ARRAYLIMIT'' would be needed, but
it would cause you to access one element off the end of the array which
is undefined.  ANSI-C only says the *address* that points to one element
beyond the end of an array must be valid.  But accessing it is undefined
behavior. [ANSI-C 3.3.6]

Assuming we had:

	foo a[ ARRARYLIMIT + 1 ];	/* also very common way */

Doesn't help either, you also stop early.

-- David	(dobrien@seas.gwu.edu)

Re: "Subtract C, add Ada"

[Samuel Mize]

In article <3gebnq$7f3@cronkite.seas.gwu.edu>,
David O'Brien <dobrien@seas.gwu.edu> wrote:

Several things that made me think harder before I wrote.
Painful, but thanks.  ;-)

Specifically, he wrote
>Code layout and where expressions may be used is what this thread was
>about.

True.

To bring it back around:

Ada was not designed to be hard to write per se, but it *was*
explicitly designed to be easy to read accurately, even when
that made it harder to write.  Note also, not just easy to
read, but easy to read *accurately.*

The designer felt that assignments embedded in expressions
were easy to miss, and easy to screw up.  This opinion is
based, in large part, on our collective experiences with
debugging C.  So, Ada does not let assignment return a value.
However, if it really really (not just really) makes your
code better somehow, Ada provides a construct with which
you can "wrap" the assignment, to make it visible that
this particular assignment returns a value.  This construct
is the function declaration.  With pragma inline and a
little attention to what you are doing, this should be
as efficient as an embedded expression, and should also
be clearer to the maintenance programmer.  For example,

>...The original
>C code was:
>	while ( (c = getchar()) == ' ' ) { /* count spaces */ }

To make truly equivalent Ada code, you would need a function,
probably in a shared file package, that assigns and returns
the next character from the file:

    package Files_Like_C is
      C: character;
      function Next_Char return character;
    end Files_Like_C;

    with Text_Io; use Text_Io;
    package body Files_Like_C is
      function Next_Char return character is
      begin
        if End_Of_File then
          C := Ascii.Nul; -- no EOF character so using NUL
        else              -- to emulate the C string terminator
          Get (C);
          return C;
        end if;
      end Next_Char;
    end Files_Like_C;

Once all this infrastructure has been set up, you can code:

    while (Next_Char = ' ') loop
      null; -- count spaces here if needed
    end loop;

Before anyone says "but look at all that code!" remember, we
are recoding the interface to the standard file package, on
the assumption that there is a compelling reason to put
Next_Char into expressions.

Sam Mize - smize@starbase.neosoft.com

Re: "Subtract C, add Ada"

[Jesper Kaagaard]

Jay Martin (jmartin@oahu.cs.ucla.edu) wrote:
: First there was:
:   Newtons Principia....
: then came:
:   Einstein's Theory of Relativity...
: And Now....
:   G E T C H A R ()!!!  BOM-BOM BOM-BOM BOM-BOM...
: ---------------------------------

: For some laughs lets look at the man page for getchar():


ehh, how old are you Martin ??

--- peter (never mind the from field)

Re: "Subtract C, add Ada"

[Charles H. Sampson]

In article <3gl06i$s03@miranda.gmrc.gecm.com>,
R.A.L Williams <bill@valiant> wrote:
>In article <1995Jan23.154631.6702@sei.cmu.edu> you(?) wrote:
>:
>: Again, I don't see it.  The Ada code makes it clear that *corresponding*
>: elements of the array Q are being copied into P - though, of course,
>: a real Ada programmer (TM) would have written just P := Q.  The C code
>: doesn't make that clear - you're going to have to ferret out the
>: initialisations of p and q to determine that.  And if you worry about
>: the correctness of the copy - for instance, whether P and Q are the
>: same size - that's surely going to be a lot easier to establish in Ada.
>
>Again, a simplified example to illustrate a principle. The point is that
>the less I have to move my eyes, or flip over pages, when reading/reviewing 
 ^^^ ^^^^ ^ ^^^^ ^^ ^^^^ ^^ ^^^^  ^^ ^^^^ ^^^^ ^^^^^
>code, the more likely I am to understand it and find any bugs. You're
>quite right, P := Q is an event more compact representation and I approve
>(the Bill Williams official statement of approval!).

     The marked phrases are what many of us Ada fans are talking about when
we use the word _readability_.  P := Q unambiguously shows that the value of
Q is being assigned to P.  To repeat you's statement, *p++ = *q++ simply
says that whatever q was pointing to gets copied to whatever p is pointing
to, after which both are modified to point to the "next" thing.  Depending
on the complexity of the code, it can take a tremendous amount of ferreting
about, moving eyes and flipping pages, to discover what p and q are pointing
to.

				    Charlie

Re: "Subtract C, add Ada"

[Robert C. Soong]

RonaldS60 (ronalds60@aol.com) wrote:

: Gary Frankel (gfrankel@rational.com) wrote
: >As of late 1989, I was involved in a commerical Ada optimizing 
: >compiler... We published results on a wide variety of benchmarks
: >(Hennessey,etc) that showed that the Ada compiler was producing
: >better code than any commercially available C compiler at that time
: >and far better than most C compilers.  This was true for workstations
: >and cross compilers.
: >
: >I cant vouch to the same degree for the current state of the art
: >since I havent done the same studies recently, but I believe
: >that you will find tha the optimizing Ada compilers can produce
: >comparable or better code than C compilers.  I have also noticed
: >that a number of C++ compilers produce poorer code - probably due
: >to the current level of maturity.

: About two years ago a IEEE article (in one of the s/w engineering
: journals) compared the percentages of dead code (I assume using some
: reachability algorithm) between Fortran, C, and C++.  The numbers
: were suprising (to say the least) and indicated that while Fortran
: had the least dead code (followed by C) C++ could have upto 60%-75%
: dead code.  The exact quantity being undecidable in a static analysis
: due to virtual function calls.  This research hasn't had any obvious
: effect on the C++ crowd (or any of the OO people) that I have seen.

: >Generally, an optimizing Ada compiler is actually at an advantage over
: >C compilers due to Ada sources providing more useful type information
: >and the aliasing problems of C.  Ada compilers will tend to 
: >compile more slowly since they do considerably more checking than
: >C compilers.

: One of the problems with aliasing is covered in an article titled 
: 'The Undecidability of Aliasing' by G. Ramalingam in ACM Transactions
: on Programming Languages and Systems, vol. 16 no. 5, September 1994.

: >So, I think that anyone who does a careful study will simply not
: >find that C has any advantages in code efficiency over Ada at all
: >(at least on any program more than a few short lines).

: Actually there was an article around 1989 to 1991 covering the 
: difference between two programs (that did the same thing) written in
: C and Ada.  They were both compiled on the best compilers that could
: be found.  C won for overall speed, by less than 2% when runtime 
: checking was disabled (as it could be when the program was validated.)
: A 1% to 2% difference in speed isn't much price to pay when the
: overall development cycle is shortened (especially in testing) as
: much as Ada allows (when compared to C.)  Just think how nice it
: would have been if that company in Redmond had used Ada instead of
: C (oooh, software that actually works! and on time! ;{))).

: >-- Gary Frankel
: >
: >
: >Mitch Gart (mg@asp.camb.inmet.com) wrote:
: >: Jay Martin (jmartin@oahu.cs.ucla.edu) wrote:
: >
: >: : I read the abstracts to these papers before I posted, there is not
: >: : one peep about the relative efficiency between C and Ada which
: >: : should be the central topic of discussion in my opinion.
: >
: >: I wrote a paper on this, which is now pretty dated, but still might
: >: possibly be of interest:
: >
: >: "Benchmarking Ada, C, and Pascal", SigAda conference, July 1986,
: >: Pittsburgh.
: >
: >:  Mitch Gart


: Ron
: ======================================================
: Computers now make it possible to make more mistakes
: more efficiently than ever before possible.
: ======================================================

Re: "Subtract C, add Ada"

[Mark S. Hathaway]

> In article <3gsr0e$oin@miranda.gmrc.gecm.com>,
> bill@valiant (R.A.L Williams) writes:

> : In article <3gnnfk$bfa@Starbase.NeoSoft.COM> Samuel Mize wrote:
 
> [summary of previous discussions...]

> : >...The original
> : >C code was:
> : >	while ( (c = getchar()) == ' ' ) { /* count spaces */ }

> : To make truly equivalent Ada code, you would need a function,
> : probably in a shared file package, that assigns and returns
> : the next character from the file:
> :
> :     package Files_Like_C is
> :       C: character;
> :       function Next_Char return character;
> :     end Files_Like_C;
> : 
> :     with Text_Io; use Text_Io;
> :     package body Files_Like_C is
> :       function Next_Char return character is
> :       begin
> :         if End_Of_File then
> :           C := Ascii.Nul; -- no EOF character so using NUL
> :         else              -- to emulate the C string terminator
> :           Get (C);
> :           return C;
> :         end if;
> :       end Next_Char;
> :     end Files_Like_C;
> :
> : Once all this infrastructure has been set up, you can code:
> :
> :     while (Next_Char = ' ') loop
> :       null; -- count spaces here if needed
> :     end loop;
> :
> : Before anyone says "but look at all that code!" remember, we
> : are recoding the interface to the standard file package, on
> : the assumption that there is a compelling reason to put
> : Next_Char into expressions.

> Never mind all that code, the main feature of the C code was that, at
> the termination of the loop, the variable 'c' contained the character
> which caused the loop to terminate. Are you suggesting a 'LastChar'
> function as well. 
> 
> Look, Ada's a great language. Its got lots of innovative features:
> built in tasking, compilable package specifications, etc. but, to me,
> and, I suspect, to numerous others, the dedication with which 'unsafe'
> constructs was eliminated went a little too far, to the detriment
> of readability.

I feel certain that the C example could be emulated in Ada or many other
languages.  What is painfully obvious now is that the author of the C
code didn't comment it in any way to say precisely what he/she was trying
to achieve with that code.  If counting spaces was intended, as many of
us thought, then the Ada "version" does quite nicely.  If the character
gotten on the last go around is needed for later then where is the C code
which uses that character.  Without some followup code it isn't obvious
to anyone that that last character will be used in the future, and yet
the poster says this was "the main feature of the C code".  I can hardly
agree.

The C version doesn't check for an eof() condition before reading stdin.
The author of the Ada code added that check.  I'm not certain it's necessry
or correct with the object in (standard input stream).  Should it ever be
at eof()?  This is a design decision rather than a programmer's choice.

  proc count_chars () is
    var c     is character := NUL;
        count is integer   := 0;
  begin
    loop
      c := in.getch();      -- could also be written:  c.assign(in.getch());
      if c <> ' ' then
        exit;               -- drops out of the loop
      else
        count.increment(1);
      end;
    end;
  end count_chars;

Anyone can cram it into a smaller form if they like...

  loop c := in.getch(); if c <> ' ' then exit; else
    count.increment(1); end; end;

but, that's hardly the point.


Mark S. Hathaway       <hathawa2@marshall.edu>

Re: "Subtract C, add Ada"

[Travis C. Porco]

hathawa2@marshall.edu (Mark S. Hathaway) writes:

> Anyone can cram it into a smaller form if they like...

>   loop c := in.getch(); if c <> ' ' then exit; else
>     count.increment(1); end; end;

> but, that's hardly the point.

Oh no, terseness is the sine qua non of a programming
language.  Characters are very expensive and should never be
wasted.  I know of whole programming projects which have been
late due to a shortage of "a"'s.  When you add in the high
import tariffs on expensive letters from abroad, you see that
short terse syntax structures like that in C are clearly
superior.  

Further, studies of programmer productivity have shown that
slow typing speed is the single largest
obstacle to being a good programmer.  
Terse languages help the typistically impaired compete in the
dog-eat-dog world of programming.

Terse languages often have a beautiful mathematical
syntax which is very appealing and provides programmers a way
to display their talents.  For instance, 
while(++p = ++q) ;
is clearly impressive, whereas
copyString(destinationFileName,targetFileName) ;
is so obvious that anyone could have done it.
Similarly, cin>>a1>>a2; and  z+=3; demonstrate the programmer's
intellectual talents and good taste far better than the
pedestrian  get list(firstName, lastName) ; 
and   add 3 to expectedTime 

Computers are easily able to count things with
no error and to keep track of scoping rules, and a good
programmer naturally will try to emulate the machine in this
regard.  

"Whoever writes the function in the fewest characters wins!"

Travis | "Before there were friendly operating system interfaces
Porco  | like the [OS/2] Workplace Shell, computer users 
       | communicated with a computer using ... instructions 
       | called *commands*."  User's Guide to OS/2 Warp, p. 154

Re: "Subtract C, add Ada"

[Fred J. McCall]

You know, I've sat and read this thread for quite some time now and all the 
Ada advocates have convinced me of one thing:

If you spent as much time bashing on Ada vendors about the quality and price 
of the tools as you spend bashing on languages that people prefer to Ada, more 
people might prefer Ada.

Re: "Subtract C, add Ada"

[Garlington KE]

Fred J. McCall (fjm@ti.com) wrote:
: You know, I've sat and read this thread for quite some time now and all the 
: Ada advocates have convinced me of one thing:

: If you spent as much time bashing on Ada vendors about the quality and price 
: of the tools as you spend bashing on languages that people prefer to Ada, more 
: people might prefer Ada.

Some of us do. I get to go to Pittsburgh next week for just that reason.
Oh joy.

--------------------------------------------------------------------
Ken Garlington                  GarlingtonKE@lfwc.lockheed.com
F-22 Computer Resources         Lockheed Fort Worth Co.

If LFWC or the F-22 program has any opinions, they aren't telling me.

"Subtract C, add Ada"

[R.A.L Williams]

In article <3h1lfl$lr4@Starbase.NeoSoft.COM> Samuel Mize wrote:
: In article <3gsr0e$oin@miranda.gmrc.gecm.com>,
: R.A.L Williams <bill@valiant> wrote:
: >Never mind all that code, the main feature of the C code was that, at
: >the termination of the loop, the variable 'c' contained the character
: >which caused the loop to terminate. Are you suggesting a 'LastChar'
: >function as well. 

: In the Ada rewrite I provided, "at the termination of the loop, the
: variable 'c' contained the character which caused the loop to
: terminate."  However, it's contained in the package Files_Like_C.

Yes, I'm sorry. You're absolutely write. In that case, I see nothing
wrong with the code, but, are you suggesting that that much code is
more 'readable' than the C equivalent. OK, this is a relatively trivial
example. Anyone who can't understand your code probably shouldn't be
reading it anyway! Nonetheless the point remains that Ada code is more
verbose than C, and this can IMO obscure, rather than enhance, readability.

: We're now discussing a difference in design philosophy in standard
: I/O packages, not a difference in the languages.  My point was that
: you could implement either I/O design philosophy in Ada.  Mr. Ichbia
: et al picked a different design for their standard I/O package,
: named Text_Io, so you will have to code your own replacement if you
: want to use C-style I/O.  Just as if you wanted to use C-style I/O
: in PL/I or Fortran.  You *can* do this.

I wasn't particularly concerned in my original postings about specific
features such as I/O libraries. I worry more about the structure of Ada
giving me more 'hoops to jump through' to the extent that code is
*less* readable. Having been involved in a fair number of code
walkthroughs recently, 'reviewer fatigue' is an important issue.

: Sam Mize - smize@starbase.neosoft.com

Bill Williams