Re: Question about Ada expressions

Re: Question about Ada expressions

[Karl Nyberg]

I had a friend call yesterday after spending five hours trying to figure out
why some C code didn't work based on this expression:

	if (variable & MASK == VALUE)

He mistook the rules of precedence, just as Robert Firth expressed it in his
response.  The K&R book explains this reasoning:

	Note that the precedence of the bitwise logical operators &, ^ and |
	falls below == (test for equality) and !=  (test for inequality).
	This implies that bit-testing expressions like

		if ((x & MASK) == 0) ...

	must be fully parenthesized to give proper results.  [p. 49]

Seems like it was kind of the Ada designers to preclude this from the
language.  Getting an error during compile time would have saved my friend
immense difficulty.  Getting a manual might have helped him, too...

-- Karl --

Re: Question about Ada expressions

[Scott Simpson]

In article <8910122337.AA06188@grebyn.com> karl@grebyn.com (Karl Nyberg) writes:
>I had a friend call yesterday after spending five hours trying to figure out
>why some C code didn't work based on this expression:
>
>	if (variable & MASK == VALUE)

Your buddy didn't use lint.  It would have caught this.
	Scott Simpson
	TRW Space and Defense Sector
	usc!trwarcadia!simpson  	(UUCP)
	trwarcadia!simpson@usc.edu	(Internet)

Re: Re^2: Ada 9X objectives

[Robert Munck]

I think that many of the participants in this discussion thread are
missing an important point:  the Ada effort is NOT primarily concerned
with the state of the art in programming languages, but rather that
of large-scale software engineering.

These are two very different things, and it is to be expected that the
programming language chosen would be different.  For example, language
stability is an important characteristic of this kind of s/w engineering;
the 10-year language upgrade period is on the same order of magnitude
(or even a bit low) as the time required for a big software project,
either DOD or commercial.  Ada is intended to reduce life-cycle costs,
and changing the language every few years would have a large negative
effect on that.

What we have here is a failure of communication between research and
practicality.  Universities and commercial research centers have very
little chance for experience in software projects that require hundreds
of programmer-years with large geographic and temporal distributions.
It is quite irrelevant to proclaim the powers of brand-new languages
until they have been used successfully in such large projects.  Has
there been a C++ development of 500,000 lines or more that has become
a product in some sense and has been widely used?  One that has been
developed by a prime/sub-contractors arrangement of a half-dozen
companies and passed on to another such group for maintenance?  Well,
Ada can't claim many such either, but it was designed for that
kind of situation.

I'd suggest that language theorists commenting on Ada first consider
the extent of their own experience with "real-world," large-scale
programming projects.  Ada can certainly be discussed as a language
independent of such concerns, but the entire DoD Ada effort can not.
                 -- Bob <Munck@MITRE.ORG>, linus!munck.UUCP
                 -- MS Z676, MITRE Corporation, McLean, VA 22120
                 -- 703/883-6688

Re: Ada 9X objectives

[William Thomas Wolfe, 2847]

From munck@chance.uucp (Robert Munck):
> I think that many of the participants in this discussion thread are
> missing an important point:  the Ada effort is NOT primarily concerned
> with the state of the art in programming languages, but rather that
> of large-scale software engineering.

   I think otherwise: the effort is not to link Ada with the state
   of the art in programming languages, but to link Ada with the
   state of the art in software engineering.
                       ^^^^^^^^^^^^^^^^^^^^ 
> These are two very different things, and it is to be expected that the
> programming language chosen would be different.  For example, language
> stability is an important characteristic of this kind of s/w engineering;
> the 10-year language upgrade period is on the same order of magnitude
> (or even a bit low) as the time required for a big software project,
> either DOD or commercial.  Ada is intended to reduce life-cycle costs,
> and changing the language every few years would have a large negative
> effect on that.

   I see no reason why lengthy projects have to switch languages in
   mid-stream UNLESS they think it will help them out.  Of course,
   given the existence of automatic translation facilities and the
   ability to exploit pragma Interface in both directions, this may
   in fact be the case. 
 
> What we have here is a failure of communication between research and
> practicality.  Universities and commercial research centers have very
> little chance for experience in software projects that require hundreds
> of programmer-years with large geographic and temporal distributions.
> It is quite irrelevant to proclaim the powers of brand-new languages
> until they have been used successfully in such large projects.  Has
> Has there been a C++ development of 500,000 lines or more that has 
> become a product in some sense and has been widely used?  One that 
> has been developed by a prime/sub-contractors arrangement of a half-dozen
> companies and passed on to another such group for maintenance?  Well,
> Ada can't claim many such either, but it was designed for that
> kind of situation.

   The prime/subcontractor arrangement exists only in the realm of
   government contracting, and hence it would be unrealistic to expect
   an exact parallel in the commercial realm.  However, there appears
   to be a substantial amount of C++ activity in industry, and some
   large products *have* been produced.  I'm not sure of the exact 
   line counts, but a quick query to comp.lang.c++ would undoubtedly 
   produce all the statistics you can eat.

   There are a lot of negative things in C++, and a lot of the good
   stuff in Ada is not available in that language.  The only two real
   advantages C++ can cite are: easy transition for C programmers, and
   multiple inheritance.  The first is not something we SHOULD worry
   about; we don't need to provide C programmers with the ability to
   do all their favorite hacks.  The second is a real problem, because
   the use of multiple inheritance is an important software engineering
   mechanism.  It reduces the amount of code that must be written, and
   increases the speed with which products can be produced.  

   By incorporating this mechanism into Ada, the sole argument for C++
   becomes the unwillingness of C/C++ programmers to give up their
   hacking ways, and this is a problem we can successfully address.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu
 

Re: Ada 9X objectives

[Dick Dunn]

William Wolfe writes about Ada 9X and C++

>    There are a lot of negative things in C++, and a lot of the good
>    stuff in Ada is not available in that language.  The only two real
>    advantages C++ can cite are: easy transition for C programmers, and
>    multiple inheritance...

This is a parochial view--something which is a perennial problem in the Ada
community, and which has done a lot to inhibit interest in Ada, let alone
acceptance of it.  If you want folks to move to Ada, you can't get it to
happen by just proclaiming the obvious, innate superiority of Ada and
waiting for them to arrive in droves.  You're going to have to try to
understand why they're using C (or C++ or whatever they're using).  There
are many reasons; there are reasons not to convert to Ada; there is
inertia.  The harder you try to dismiss their reasons by working from your
own viewpoints, the less credibility you have.  (The reasons may not even
be good ones!  They still have to be addressed.)

The credibility problems only get worse as you deal with more experienced
software people.  The longer people have watched and worked in software,
the more alleged panaceas they've seen, and the more sure they are that
there aren't any panaceas.  Also, it's likely that they've worked in some
truly awful languages and have produced decent software in spite of it, so
they'll doubt that the choice of programming language is as important as
you say.  Finally, they'll have been watching the progress of Ada over the
years and will have concluded that with the enormous amount of money thrown
at it, if it were truly wonderful it would have really caught on by now.

Part of what I'm saying is that you've got a marketing problem.  Even if
you have a wonderful product, you still have to sell it--you'll go broke if
you just wait for customers to find you.  And a lot of us aren't convinced
that the product is all that wonderful anyway.

[Wolfe finishing up on importance of multiple inheritance]
>    By incorporating this mechanism into Ada, the sole argument for C++
>    becomes the unwillingness of C/C++ programmers to give up their
>    hacking ways, and this is a problem we can successfully address.

This is flawed in several ways.  The first is the attitude that C/C++
programmers have "hacking ways" somehow tied to the language, and that they
can be corrected by setting them on the One True Path to Ada.  Look, this
is arrogant on the part of Ada folks and demeaning toward the C/C++ folks.
You should be able to see that this sort of attitude won't cut it, *regard-
less* of how much you like Ada or dislike C++!  The arrogant and insular
attitudes of Ada's adherents have done far more damage to the language than
the lack of any feature could do.

Also, the argument that you can just add multiple inheritance and win the
battle is based on the assumption that C++ is now static, that it's not
going to acquire any more useful features.  I suspect strongly that this is
a mistaken assumption.  You had better assume that you are aiming at a
moving target.  If you want anything approaching a contemporary programming
language, you're not going to get it by taking five years to get to where
C++ is now, and then proclaiming you're done.  The activity and adaptability
of C++ is something you're going to have to address somehow if you're going
to "compete" with it.

Beyond that, if you just add a feature to Ada, it doesn't immediately
become as useful as a feature that's existed in C++ for a while.  There's a
maturing period, during which people find the gotchas and evolve the
paradigms.
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...No DOS.  UNIX.

Question about Ada expressions

[Perry Schmidt]

In Ada, when building boolean expressions you must put ANDs and ORs (and
OR ELSES, etc) in parents IF you use them in mixed combination.

Ex.  (A and B or C) -- is not legal.  You must write it as...
     (A and (B or C))

So the question is -- WHY?

Does this remove some semantic ambiguity?  Or is it just the "Ada style!"

Thanks for any responses...

Perry Schmidt
(schmidt@green.cs.wisc.edu)

Re: Question about Ada expressions

[STEPHEN D. STRADER]

In article <8834@spool.cs.wisc.edu> schmidt@green.cs.wisc.edu (Perry Schmidt) writes:
>In Ada, when building boolean expressions you must put ANDs and ORs (and
>OR ELSES, etc) in parents IF you use them in mixed combination.
>Ex.  (A and B or C) -- is not legal.  You must write it as...
>     (A and (B or C))
>So the question is -- WHY?

BECAUSE!

No, actually it is to remove ANY ambiguity as to how the expression
should be evaluated.  

Saright?

S

Re: Question about Ada expressions

[Robert Firth]

In article <8834@spool.cs.wisc.edu> schmidt@green.cs.wisc.edu (Perry Schmidt) writes:

>In Ada, when building boolean expressions you must put ANDs and ORs (and
>OR ELSES, etc) in parents IF you use them in mixed combination.

>So the question is -- WHY?

There is no problem of semantic ambiguity, any more than with, say,
A + B*C.  The reason for the restriction is that one of the language
designers believed the relative priorities of the Boolean operators
were sufficiently unfamiliar to the general run of programmers that
expressions such as

	A and B or C

could cause confusion or, worse, be misinterpeted.

Re: Question about Ada expressions

[stt]

Ada tried to use the "conventional" precedence
rules when defining operators.  However, it has
never been entirely clear where XOR belongs relative
to AND and OR, nor how regular AND
and short-circuit AND THEN should
fare relative to one another.  The net result
was that they "punted" in this area and said
use parentheses when using two logical operators
in sequence.  

It might have been ideal in some
people's mind if at least AND had clearly higher precedence 
than OR so that your example could be coded without
parentheses, but Ada has always tried to err
on the side of readability over writability.

S. Tucker Taft
Intermetrics, Inc.
Cambridge, MA

Re: Question about Ada expressions

[horst]

In article <8834@spool.cs.wisc.edu> schmidt@green.cs.wisc.edu (Perry Schmidt) writes:
>
>In Ada, when building boolean expressions you must put ANDs and ORs (and
>OR ELSES, etc) in parents IF you use them in mixed combination.
>...
>Does this remove some semantic ambiguity?  Or is it just the "Ada style!"

Yes, there is an ambiguity. The precedence of 'and' and 'or'
is not so commonly agreed as that of '*' and '+'. So the
designers chose to require parenthesis.
Regards,
 horst