Re: Software landmines (was: Why C++ is successful)

Re: Software landmines (was: Why C++ is successful)

[dewar]

<<A 'return', at least in C/C++/VB, returns you to the place the current
procedure was called from.  'goto' control flow can be endlessly channeled
here and there and never has to return to where the initial linear control
flow was originally diverted.  That seems to be a huge advantage of 'return'
over 'goto'.
>>

No, it is a huge advantage of return over a *bad* use of goto. But nearly
every feature in a language can be badly misused. We didn't eliminate
assignments from Ada, even though they can be (and are all the time)
horribly misused, and even though we know perfectly well that you can
write programs with no assignments with no loss in expressive power.

Instead we left in the assignment, and wise programmers use it to improve
the clarity of their programs, and foolish programmers create havoc with
it (by the way most programmers furiously overuse assignments, and it is
far too common to see a variable assignment used to establish a constant
value -- of course languages like traditional C which have no capability
for defining constants aggravate the problem!)

The goto is the same, wise programmers use it occasionally to clarify
their code, foolish programmers create havoc with it (although this happens
less often, since people are FAR more aware of the goto danger than the
assignment danger).

Fanatics in both cases decry straying from the pure road (yes there
are plenty of people who consider an assignment statement as just as
evil as a goto, and would not dream of using either :-)

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Software landmines (was: Why C++ is successful)

[dewar]

In article <dale-2308981004320001@dale.ppp.cs.rmit.edu.au>,
  dale@cs.rmit.edu.au (Dale Stanbrough) wrote:
> dewar@gnat.com wrote:
>
> "No, it is a huge advantage of return over a *bad* use of goto. But nearly
>  every feature in a language can be badly misused. We didn't eliminate
>  assignments from Ada, even though they can be (and are all the time)
>  horribly misused, and even though we know perfectly well that you can
>  write programs with no assignments with no loss in expressive power."
>
> Do you have examples of the bad/excessive use of assignment statements?
>
> Dale
>

Well of course there are many programmers, who in a manner
analogous to the "gotophobes" consider *any* assignment statement
as anathematic, and prefer languages where no assignments are
allowed. It is of course common knowledge that assignment
statements are unnecessary, and that just as it is possible to
program without gotos, it is possible to program without
assignment statements. Indeed it is a good excercise at least
to make students learning Ada or some other reasonable language
that has appropriate features, write a program avoiding
assignment statements completely.

But in normal use of a language like Ada, it certainly is
relatively unlikely that many people would agree to this kind
of extremism. It is actually probably the case that many Ada
programmers would find the notion of programming without
assignments as bizarre and foreign (in much the same way as
a Fortran-67 programmer considers programming without gotos
as bizarre, oops, that should be Fortran66).

As for programs that overuse assignments these are indeed
common. In fact it is rare that I see a big Ada program that
does not have instances of initialized declarations of variables
without a constant keyword that are in fact constants.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Software landmines (was: Why C++ is successful)

[Andi Kleen]

dale@cs.rmit.edu.au (Dale Stanbrough) writes:

> dewar@gnat.com wrote:
> 
> "No, it is a huge advantage of return over a *bad* use of goto. But nearly
>  every feature in a language can be badly misused. We didn't eliminate
>  assignments from Ada, even though they can be (and are all the time)
>  horribly misused, and even though we know perfectly well that you can
>  write programs with no assignments with no loss in expressive power."
> 
> Do you have examples of the bad/excessive use of assignment statements?

Assignments are equivalent to gotos. Just write the function as a big
loop case .. statement, then you can use assignments as goto.

In functional programming languages like ML or Scheme it is possible
and easy to write assignless code, but these have lots of special tools
(e.g. easy closures) that make that easier.

-Andi

Re: Software landmines (was: Why C++ is successful)

[Dale Stanbrough]

dewar@gnat.com wrote:

"No, it is a huge advantage of return over a *bad* use of goto. But nearly
 every feature in a language can be badly misused. We didn't eliminate
 assignments from Ada, even though they can be (and are all the time)
 horribly misused, and even though we know perfectly well that you can
 write programs with no assignments with no loss in expressive power."

Do you have examples of the bad/excessive use of assignment statements?


Dale

Re: Software landmines (was: Why C++ is successful)

[Richard D Riehle]

In article <6rnhhe$e2u$1@nnrp1.dejanews.com>,
	dewar@gnat.com wrote:

>... We didn't eliminate
>assignments from Ada, even though they can be (and are all the time)
>horribly misused, and even though we know perfectly well that you can
>write programs with no assignments with no loss in expressive power.

 I cannot imagine writing a large program totally devoid of assignment
 statements.  In fact, I sometimes see people programming around the
 assignment by parenthetical nesting of function returns and find it
 confusing, reminsicent of the German sentences of philosophers who,
 in an attempt to extract every nuance from an idea without leaving any
 possibility for misinterpretation, along with, what seems to be an
 attempt to avoid using an excessive number of periods in their sentences,
 construct long, dependent clause-filled sentences, the effect of which
 is to leave one, if, in fact, one is still reading, without any sense
 of what the original idea might have been from the beginning.

 Don't take away my assignment statements, Robert.  The help me write
 crisp, short code sentences that ordinary mortals can understand. In
 fact, as an old time Fortranner, I sometimes write a function that
 looks like,

       function F ( ... ) return some-data-type is
         Result : some-data-type := initial-value;
       begin
         Result := algorithmic-part;
         return Result;
       end F;

>... most programmers furiously overuse assignments, and it is
>far too common to see a variable assignment used to establish a constant
>value 

  I am not sure what you mean.  If I want to define constants,

          Zero : constant := 0;
          Null_List := some-value;

  how do I set the initial value without assignment.  For private
  members in C++ this is really easy without assignment.  I can use
  (must use) an initialization list.  In Ada we have to have an 
  assignment somewhere to make this happen.

of course languages like traditional C which have no capability
>for defining constants aggravate the problem!)

  But this is not true for C++ where one can use the initialization
  list as shown above and one can even define a function as a const, the
  parameters as const, etc.  In this respect, C++ is a little more
  powerful (read, safer) than Ada especially when using pointers as  
  parameters. For lots of other reasons, I still prefer Ada.

  Richard Riehle
  richard@adaworks.com
  www.adaworks.com

  

 

Re: Software landmines (was: Why C++ is successful)

[dennison]

In article <6rsg0d$pcj@dfw-ixnews3.ix.netcom.com>,
  Richard D Riehle <laoXhai@ix.netcom.com> wrote:

>  statements.  In fact, I sometimes see people programming around the
>  assignment by parenthetical nesting of function returns and find it
>  confusing, reminsicent of the German sentences of philosophers who,
>  in an attempt to extract every nuance from an idea without leaving any
>  possibility for misinterpretation, along with, what seems to be an
>  attempt to avoid using an excessive number of periods in their sentences,
>  construct long, dependent clause-filled sentences, the effect of which
>  is to leave one, if, in fact, one is still reading, without any sense
>  of what the original idea might have been from the beginning.

Wow. You even write self-documenting prose. :-)

--
T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Software landmines (was: Why C++ is successful)

[Andi Kleen]

Richard D Riehle <laoXhai@ix.netcom.com> writes:
> 
>  Don't take away my assignment statements, Robert.  The help me write
>  crisp, short code sentences that ordinary mortals can understand. In
>  fact, as an old time Fortranner, I sometimes write a function that
>  looks like,
> 
>        function F ( ... ) return some-data-type is
>          Result : some-data-type := initial-value;
>        begin
>          Result := algorithmic-part;
>          return Result;
>        end F;

I think you misunderstand. Even purely functional languages like ML have
a way to write this so that you don't have to put the complete program
into one expression. What they don't have, and I think that is what Robert
was refering to, is a way to cause side effects and change the program state
by an assignment.

-Andi

Re: Software landmines (was: Why C++ is successful)

[Brian Rogoff]

On 25 Aug 1998, Andi Kleen wrote:
> Richard D Riehle <laoXhai@ix.netcom.com> writes:
> > 
> >  Don't take away my assignment statements, Robert.  The help me write
> >  crisp, short code sentences that ordinary mortals can understand. In
> >  fact, as an old time Fortranner, I sometimes write a function that
> >  looks like,
> > 
> >        function F ( ... ) return some-data-type is
> >          Result : some-data-type := initial-value;
> >        begin
> >          Result := algorithmic-part;
> >          return Result;
> >        end F;
> 
> I think you misunderstand. Even purely functional languages like ML have

I think ML is what most FPers would call impure, since the MLs that I know 
of, SML and CAML, both have assignable references. ML is "functional" in 
that it has higher-order functions, but the designers of ML consciously 
included assignment. 

If you look closely, you can see a little bit of ML in Ada-95. 

-- Brian

Re: Software landmines (was: Why C++ is successful)

[Matthew Heaney]

Richard D Riehle <laoXhai@ix.netcom.com> writes:

> >... most programmers furiously overuse assignments, and it is
> >far too common to see a variable assignment used to establish a constant
> >value 
> 
>   I am not sure what you mean.  If I want to define constants,
> 
>           Zero : constant := 0;
>           Null_List := some-value;
> 
>   how do I set the initial value without assignment.  For private
>   members in C++ this is really easy without assignment.  I can use
>   (must use) an initialization list.  In Ada we have to have an 
>   assignment somewhere to make this happen.

The issue lies in the difference between "assignment" and "binding."
The problem with Ada is that the syntax for both is the same, so
whenever people see ":=" they always think of assignment, even when it
really means binding.

In the example above, 

   Zero : constant := 0;

is a binding operation, not an assignment operation.  The name Zero is
bound to a value.

Indeed, any time you see the keyword "constant" in a declaration, then
you should treat that to mean "bind," not "assign."

Ada is wildly inconsistent wrt binding.  To bind a name to a function, I
use the keyword "is":

function F (X : T1) return T2 is
begin
   <body>
end F;

means the same thing as

type FT is function (X : T1) return T2;

F : constant FT := begin <body> end;

Why not use the operator "is" everywhere binding is intended?

I think it's true that in Eiffel, binding doesn't use the assignment
operator, it uses the keyword "is", as in

   Zero : Integer is 0;

which is the equivalent of

   Zero : constant Integer := 0;

in Ada.

So when Robert says "programmers misuse assignment," he means (I think)
that they are using assignment when they really want to use binding.
The latter use is indicating by the presence of the keyword "constant".

Unfortunately, the syntax for binding in Ada also uses the assignment
operator, so Ada programmers blur the distinction between binding and
assignment (if they are aware of it at all).  I regard this as a flaw in
the language.

Re: Software landmines (was: Why C++ is successful)

[Richard D Riehle]

In article <m3g1eithld.fsf@mheaney.ni.net>,
	Matthew Heaney <matthew_heaney@acm.org> wrote:

In response to Richard Riehle's question about initialization
of values with the assignment statement, 

>
>The issue lies in the difference between "assignment" and "binding."

 I ran to my bookshelf to find an entry in any computer science text
 on "binding" in the context you have used it.  None.  Reference, please.

>The problem with Ada is that the syntax for both is the same, so
>whenever people see ":=" they always think of assignment, even when it
>really means binding.

 I understand the distinction, and your reference to Eiffel, below, is 
 correct.  

>In the example above, 
>   Zero : constant := 0;
>is a binding operation, not an assignment operation.  The name Zero is
>bound to a value.

 So, in this respect, C++ initialization lists better express the
 "binding" requirement than Ada assignments.  
 
>Indeed, any time you see the keyword "constant" in a declaration, then
>you should treat that to mean "bind," not "assign."
>Ada is wildly inconsistent wrt binding.  To bind a name to a function, I
>use the keyword "is":
>
>function F (X : T1) return T2 is
>begin
>   <body>
>end F;
>
>means the same thing as
>
>type FT is function (X : T1) return T2;
>
>F : constant FT := begin <body> end;
>
>Why not use the operator "is" everywhere binding is intended?

 Your function example is interesting.  In an Eiffel feature
 declaration, the syntatical placement for "is" in declaring
 a function is the same as Ada rather than as you prefer. 

>I think it's true that in Eiffel, binding doesn't use the assignment
>operator, it uses the keyword "is", as in
>
>   Zero : Integer is 0;
>
This is true.  A feature declaration in Eiffel is the same for any
declaration.  This is called by Bertrand, "the principle of minimum
surprise."   When referencing any feature in an Eiffel class, the 
client of the class sees attributes identically to functions.  An
"is" is used only for constant or routine feature. Non-constant
attributes are not initialized with a "is" keyword. Also, the Eiffel
model for "attachment" and "reattachment" more closely approximates
what you and Robert are describing as alternatives to excessive use
of the assignment statement.

With that understanding in place, I suggest that, in using the
assignment operation for defining constants, the difference between
"binding" and "assignment" is a rather subtle semantic issue for most
practical programmers.  Also, several consecutive assignment statements
in Ada will often be more readable than the parentheticaly clauses
of function returns that serve as their substitute.  Ada, unlike Eiffel,
is not designed to reduce the number of assignment statements.  

The suggestion that we use fewer assignment statements is liable to 
create the same mess that "gotoless" programming fomented in the COBOL
world.  Robert knows that pre-ANSI 85 COBOL was inadequately designed
to support programs without GO TO statements.  Only with the advent
of "END ..." constructs did COBOL become more amenable to reducing the
number of GO TO's.  Ada is designed to encourage the use of the 
assigment statement.  Suggesting that we do not use it so often is 
probably counterproductive and can only be realized with some important
changes in the language.

You have already noted some of these, Matthew.

Richard Riehle
richard@adaworks.com
http://www.adaworks.com


 

Re: Software landmines (was: Why C++ is successful)

[Matthew Heaney]

Richard D Riehle <laoXhai@ix.netcom.com> writes:

>  So, in this respect, C++ initialization lists better express the
>  "binding" requirement than Ada assignments.  

One of the areas in Ada in which the assignment vs initialization issue
arises is in the declaration of limited types:

declare
   O : LT;
begin
   Initialize (O);
   <use O>

The thing I find distasteful here is that the initialization of object O
occurs after its declaration.  Sometimes this means the state of O is
undefined.  (However, many times limited objects come with a defined,
default state.  For example, Is_Open is defined to return False for a
newly declared instance of File_Type.)

I've advocated in the past that the language syntax should be amended to
add an initialization operation ("constructor"):

declare
   File : File_Type'Open (In_Mode, "matt.dat");
begin

We could even use the constant keyword in such a declaration.

> Also, several consecutive assignment statements in Ada will often be
> more readable than the parentheticaly clauses of function returns that
> serve as their substitute.

Agree.  I often see programmers use many nested function calls in an
expression.  What I have to do then is to mentally unravel the
expression.  So why not save me the trouble?  Use a declare block to
declare a few intermediate objects, and feed them to the ultimate
subprogram call.

> The suggestion that we use fewer assignment statements is liable to 
> create the same mess that "gotoless" programming fomented in the COBOL
> world.  

Let's make sure everyone knows what this means:

o It DOES mean "don't use a variable when a constant will do."

o It does NOT mean "use nested function calls to return intermediate
values, instead of declaring intermediate constant objects"

Yes, you really should use constant object declarations to hold
intermediate values, even though this requires a few more "assignments."
(The scare quotes are there to remind the reader that the declaration of
a constant object isn't really an assignment.)

> Ada is designed to encourage the use of the assigment statement.

Yes.  Far too few programmers use declare blocks and constant object
declarations to simplify complex expressions.  Instead of

Op (Get_A (10), Get_B (X), Get_C (Y));

it's better to do

declare
   A : constant Integer := Get_A (10);
   B : constant Float := Get_B (X);
   C : constant Boolean := Get_C (Y);
begin
   Op (A, B, C);
end;

As we have noted, the declarations above aren't really "assignment"
statements.  They are "binding" operations.  The distinction would be
more clear (and consistent) if the language allowed you to say:

declare
   A : Integer is Get_A (10);
   B : Float is Get_B (X);
   C : Boolean is Get_C (Y);
begin
   Op (A, B, C);
end;

The "renames" clause is a binding operator in Ada (although technically
it binds a name to an object, not a value).  A hip way to do the above
directly in the language is

declare
   A : Integer renames Get_A (10);
   B : Float renames Get_B (X);
   C : Boolean renames Get_C (Y);
begin
   Op (A, B, C);
end;

That way we can avoid the use of the assignment operator, so the
declaration won't be confused with an assignment statement.  

It's a bit of a bummer that we have 3 ways ("constant T :=", "renames",
"is") of doing essentially the same thing.  Why not just one way?

> Suggesting that we do not use it so often is probably
> counterproductive and can only be realized with some important changes
> in the language.

An unambiguous way to say this is that, in a declaration, you should use
the keyword "constant" whenever the object doesn't change its value.

Yet another way to say this is "don't use assignment when you really
mean binding."

Matt

P.S. About the meaning of binding: let me dig up my books on programming
language theory.  You usually see it mentioned in books about functional
programming, and in explications of denotational semantics.

Re: Software landmines (was: Why C++ is successful)

[Matthew Heaney]

Richard D Riehle <laoXhai@ix.netcom.com> writes:

> >The issue lies in the difference between "assignment" and "binding."
> 
>  I ran to my bookshelf to find an entry in any computer science text
>  on "binding" in the context you have used it.  None.  Reference, please.

Here are some references:

Programming Language Concepts and Paradigms
David A. Watt

Programming Languages: Design and Implementation
Terrence W. Pratt and Marvin V. Zelkowitz

Principles of Programming Languages
R.D. Tennent

Programming Language Structures
Carlo Ghezzi and Mehdi Jazayeri

Although they're a bit heavy on the theory, you might also want to take
a look at:

Introduction to the Theory of Programming Languages
Bertrand Meyer

The Denotational Description of Programming Languages
Michael Gordon

The Meyer book contains a good description of the meaning of assignment.

Hope that helps,
Matt

Re: Software landmines (was: Why C++ is successful)

[Richard D Riehle]

Brian,

Silly indeed!  I do not appreciate your use of the pejorative "silly"
in response to my postingsince it seems to be a deliberate insult. I do
admit that my hastily composed example could have been coded with more
clarity. It did not occur to me that I would need to submit a perfect code
example to make such a simple point but, since martinets abound, I submit a
new, probably unnecessary, example.  In case you have missed my original
point in your zeal to criticize the code fragment, it is as follows: Ada is
designed to encourage use of the assignment statement if we also want our
code to be clear and readable.  This was in response to Robert's (correct)
assertion that programmers use assignment statements too liberally.     

I am appending your code example and mine in case some masochist wants to
read it.  I hope you understand that my example was not intended to
represent real code.  Perhaps the way I wrote the assignment statement
confused you regarding my intentions.  I concur that, if there is a simple
algorithm, it can be stated as part of the declaration.  In the kind of
function I had in mind, there could be multiple possible values for the
Result.  In this case, the choice is between,

       Example (1)
         function F1 (paramter-list) return Result-type is
             Result : Result-type := initial-value;
         begin
           if condition-1 then
              Result := result-1;
           elsif condition-2 then
              Result := result-2;
           else
              Result := result-3;
           end if;
           return Result;
         end F1;

    versus Example(2)

         function F2 (paramter-list) return Result-type is
         begin
           if condition-1 then
              return result-1;
           elsif condition-2 then
              return result-2;
           else
              return result-3;
           end if;
           return Result;
         end F2;

The two (simplified) functions epitomize the debate about a particular
coding style. Example(2) illustrates how functions avoid using an
extraneous assignment statement.  Some practitioners prefer Example(1).
I use both in my coding. It depends on the complexity of the function,
my audience (everyone on the project is an ex-Fortranner), along with
several helpings of intuition.  Over the years I have found that 
Example(1) has been less error-prone and easier for the average programmer
to maintain.  Your mileage may vary according your experience.

-- ==================== Original Postings ====================
-- What follows is my original message along with Mr. Orpin's 
-- rather impolite reply.  
-- ===========================================================


In article <35eca5d9.4354839@news.geccs.gecm.com>,
	abuse@borpin.demon.co.uk (Brian Orpin) wrote:

in response to the following code fragment submitted by me,

>On Mon, 24 Aug 1998 19:47:31 GMT, Richard D Riehle
><laoXhai@ix.netcom.com> wrote:
>
>> Don't take away my assignment statements, Robert.  The help me write
>> crisp, short code sentences that ordinary mortals can understand. In
>> fact, as an old time Fortranner, I sometimes write a function that
>> looks like,
>
>>       function F ( ... ) return some-data-type is
>>         Result : some-data-type := initial-value;
>>       begin
>>         Result := algorithmic-part;
>>         return Result;
>>       end F;
>
>Which of course is pretty silly <g>.  Result has a default value that is
>never used.  Could easily be written..
>
>function F ( ... ) return some-data-type is
>	Result : some-data-type := algorithmic-part;
>begin
>	return Result;
>end F;
>
>or even 
>
>function F ( ... ) return some-data-type is
>begin
>	return algorithmic-part;
>end F;
>
>YMMV

 

Re: Software landmines (was: Why C++ is successful)

[John G. Volan]

Matthew Heaney wrote:
> 
> Yes.  Far too few programmers use declare blocks and constant object
> declarations to simplify complex expressions.  Instead of
> 
> Op (Get_A (10), Get_B (X), Get_C (Y));
> 
> it's better to do
> 
> declare
>    A : constant Integer := Get_A (10);
>    B : constant Float := Get_B (X);
>    C : constant Boolean := Get_C (Y);
> begin
>    Op (A, B, C);
> end;

There's a subtle difference between these two examples:  In the latter
case, the local constant declarations will be elaborated in the
indicated order, so the function calls are going to be done
sequentially.  But in the former case, the language defines no
particular order of evaluation of the actual procedure parameters, so
these function calls might occur in any order.  A smart compiler for the
right kind of target machine may even be able to schedule these calls to
occur in parallel. 

...
> The "renames" clause is a binding operator in Ada (although technically
> it binds a name to an object, not a value).  A hip way to do the above
> directly in the language is
> 
> declare
>    A : Integer renames Get_A (10);
>    B : Float renames Get_B (X);
>    C : Boolean renames Get_C (Y);
> begin
>    Op (A, B, C);
> end;

I'm curious: Does this have the same effect as the above, i.e., are the
function calls forced into a sequential order?  Or is their evaluation
deferred until the aliases A, B, and C are actually used as parameters
to the Op call, in which case the aliased function calls get executed in
an undefined order?

-- 
indexing
   description: "Signatures for John G. Volan"
   self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe"
   two_cents: "Java would be even cooler with Eiffel's assertions/DBC, %
              %generics, true MI, feature adaptation, uniform access, %
              %selective export, expanded types, etc., etc..."
class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant
   disclaimer: not (opinion implies employer.opinion)
end -- class JOHN_VOLAN_SIGNATURE

Re: Software landmines (was: Why C++ is successful)

[Mats Weber]

John G. Volan wrote:

> > declare
> >    A : Integer renames Get_A (10);
> >    B : Float renames Get_B (X);
> >    C : Boolean renames Get_C (Y);
> > begin
> >    Op (A, B, C);
> > end;
> 
> I'm curious: Does this have the same effect as the above, i.e., are the
> function calls forced into a sequential order?  Or is their evaluation
> deferred until the aliases A, B, and C are actually used as parameters
> to the Op call, in which case the aliased function calls get executed in
> an undefined order?

Yes, it has the same effect. Each function call is evaluated during the
elaboration of the renames it appears in. You are in fact renaming the object
that contains the function result. (See RM 3.3(10)).

Re: Software landmines (was: Why C++ is successful)

[dewarr]

In article <35F3FF42.D1E163E0@elca-matrix.ch>,
  Mats.Weber@elca-matrix.ch wrote:
> John G. Volan wrote:
>
> > > declare
> > >    A : Integer renames Get_A (10);
> > >    B : Float renames Get_B (X);
> > >    C : Boolean renames Get_C (Y);
> > > begin
> > >    Op (A, B, C);
> > > end;
> >
> > I'm curious: Does this have the same effect as the above, i.e., are the
> > function calls forced into a sequential order?  Or is their evaluation
> > deferred until the aliases A, B, and C are actually used as parameters
> > to the Op call, in which case the aliased function calls get executed in
> > an undefined order?
>
> Yes, it has the same effect. Each function call is evaluated during the
> elaboration of the renames it appears in. You are in fact renaming the object
> that contains the function result. (See RM 3.3(10)).
>


I must say that I find the renaming of function calls
like this to be a confusing oddity. It seems much clearer
to me to use ordinary constant declarations. The two
seem completely equivalent!

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Software landmines (was: Why C++ is successful)

[Tucker Taft]

dewarr@my-dejanews.com wrote:
: In article <35F3FF42.D1E163E0@elca-matrix.ch>,
:   Mats.Weber@elca-matrix.ch wrote:
: > John G. Volan wrote:
: >
: > > > declare
: > > >    A : Integer renames Get_A (10);
: > > >    B : Float renames Get_B (X);
: > > >    C : Boolean renames Get_C (Y);
: > > > begin
: > > >    Op (A, B, C);
: > > > end;
: > >
: > > I'm curious: Does this have the same effect as the above, i.e., are the
: > > function calls forced into a sequential order?  Or is their evaluation
: > > deferred until the aliases A, B, and C are actually used as parameters
: > > to the Op call, in which case the aliased function calls get executed in
: > > an undefined order?
: >
: > Yes, it has the same effect. Each function call is evaluated during the
: > elaboration of the renames it appears in. You are in fact renaming the object
: > that contains the function result. (See RM 3.3(10)).
: >


: I must say that I find the renaming of function calls
: like this to be a confusing oddity. It seems much clearer
: to me to use ordinary constant declarations. The two
: seem completely equivalent!

They are equivalent unless the result type is return-by-reference.

If the result-type is return-by-reference, only the rename would be legal, 
and simply denotes the same object denoted by the original return statement's
expression.  

If the result-type is the more common return-by-reference,
then the two are equivalent for all intents and purposes, though you
might think that the renaming approach could result in fewer copies
in some (not-too-smart ;-) compilers.

By the way, the original point that a "smart" compiler can parallelize:

   Op(Get_A(..), Get_B(..), Get_C(..))

more easily than the "sequential" form involving named constants is a
bit bogus.  To parallelize, the compiler needs to prove that Get_A, 
Get_B, and Get_C don't interfere with one another.  Given that, there 
is no reason that the "sequential" form couldn't be parallelized as well.

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar Company

Precalculation of parameters (was: Software landmines)

[dennison]

In article <Eyz7Co.J4t.0.-s@inmet.camb.inmet.com>,
  stt@houdini.camb.inmet.com (Tucker Taft) wrote:

> By the way, the original point that a "smart" compiler can parallelize:
>
>    Op(Get_A(..), Get_B(..), Get_C(..))
>
> more easily than the "sequential" form involving named constants is a
> bit bogus.  To parallelize, the compiler needs to prove that Get_A,
> Get_B, and Get_C don't interfere with one another.  Given that, there
> is no reason that the "sequential" form couldn't be parallelized as well.

But if the language specifically states that the order of evaluation of
parameters is undefined, then it doesn't have to prove they don't interfere.
It can just assume they shouldn't. I don't know if that's the way Ada is
defined, but I believe that was the claim that was being made.

Is that actually the rule?

--
T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Precalculation of parameters (was: Software landmines)

[dennison]

In article <Ez0tp1.59L.0.-s@inmet.camb.inmet.com>,
  stt@houdini.camb.inmet.com (Tucker Taft) wrote:
> dennison@telepath.com wrote:
>
> : Is that actually the rule?
>
> RM95 6.4(10) permits evaluation of parameters in an "arbitrary"
> order.   RM95 1.1.4(18) defines "arbitrary" order, indicating
> that it must be an order that is equivalent to some sequential
> ordering.                                      ^^^^^^^^^^^^^^^
  ^^^^^^^^

Ahhh. That was the part I was missing. So language was specifically added to
the RM to prevent compilers from blindly parallelizing this. Out of
curiosity, what was the reason this was done? I can't find anything about it
in the Rationale.

--
T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Precalculation of parameters (was: Software landmines)

[Tucker Taft]

dennison@telepath.com wrote:

: In article <Eyz7Co.J4t.0.-s@inmet.camb.inmet.com>,
:   stt@houdini.camb.inmet.com (Tucker Taft) wrote:

: > By the way, the original point that a "smart" compiler can parallelize:
: >
: >    Op(Get_A(..), Get_B(..), Get_C(..))
: >
: > more easily than the "sequential" form involving named constants is a
: > bit bogus.  To parallelize, the compiler needs to prove that Get_A,
: > Get_B, and Get_C don't interfere with one another.  Given that, there
: > is no reason that the "sequential" form couldn't be parallelized as well.

: But if the language specifically states that the order of evaluation of
: parameters is undefined, then it doesn't have to prove they don't interfere.
: It can just assume they shouldn't. 

Running two computations in parallel is very different
from running them in an "arbitrary" (but still sequential) order.  
Suppose each function adds one to the global variable "Count".  You 
get the same result independent of which order the functions are 
evaluated, but you don't get the same result if you run them in parallel,
and the machine instructions involved in adding one to the
global are interleaved arbitrarily.

: ... I don't know if that's the way Ada is
: defined, but I believe that was the claim that was being made.

: Is that actually the rule?

RM95 6.4(10) permits evaluation of parameters in an "arbitrary"
order.   RM95 1.1.4(18) defines "arbitrary" order, indicating
that it must be an order that is equivalent to some sequential
ordering.  If you have the annotated RM, it explicitly mentions
the example given above in AARM 1.1.4(18.d).

: --
: T.E.D.

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Re: Precalculation of parameters (was: Software landmines)

[Tucker Taft]

dennison@telepath.com wrote:

: In article <Ez0tp1.59L.0.-s@inmet.camb.inmet.com>,
:   stt@houdini.camb.inmet.com (Tucker Taft) wrote:
: > dennison@telepath.com wrote:
: >
: > : Is that actually the rule?
: >
: > RM95 6.4(10) permits evaluation of parameters in an "arbitrary"
: > order.   RM95 1.1.4(18) defines "arbitrary" order, indicating
: > that it must be an order that is equivalent to some sequential
: > ordering.                                      ^^^^^^^^^^^^^^^
:   ^^^^^^^^

: Ahhh. That was the part I was missing. So language was specifically added to
: the RM to prevent compilers from blindly parallelizing this. Out of
: curiosity, what was the reason this was done? I can't find anything about it
: in the Rationale.

All code within a single task is defined to be "sequential." This
is critical to being able to prove things about safe access to global
variables.  If the RM allowed parallel evaluation of parameter expressions,
all of the discussion in RM95 9.10 about sharing variables between tasks and
about "independent addressability" would have to apply to sharing variables 
and manipulating neighboring packed-array components between different 
parameter evaluations, which would dramatically increase the likelihood 
of erroneous execution per 9.10(11).

See RM95 9.10 for a discussion of these issues.  The critical paragraph
is 9.10(13), where any two actions that occur as part of the execution
of a single task are defined to be "sequential."  In some ways, that
*is* the definition of a "task."

: --
: T.E.D.

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Re: Precalculation of parameters (was: Software landmines)

[dewarr]

In article <Ez28B6.DMI.0.-s@inmet.camb.inmet.com>,
  stt@houdini.camb.inmet.com (Tucker Taft) wrote:
> dennison@telepath.com wrote:
>
> : In article <Ez0tp1.59L.0.-s@inmet.camb.inmet.com>,
> :   stt@houdini.camb.inmet.com (Tucker Taft) wrote:
> : > dennison@telepath.com wrote:
> : >
> : > : Is that actually the rule?
> : >
> : > RM95 6.4(10) permits evaluation of parameters in an "arbitrary"
> : > order.   RM95 1.1.4(18) defines "arbitrary" order, indicating
> : > that it must be an order that is equivalent to some sequential
> : > ordering.                                      ^^^^^^^^^^^^^^^
> :   ^^^^^^^^
>
> : Ahhh. That was the part I was missing. So language was specifically added
to
> : the RM to prevent compilers from blindly parallelizing this. Out of
> : curiosity, what was the reason this was done? I can't find anything about
it
> : in the Rationale.
>
> All code within a single task is defined to be "sequential." This
> is critical to being able to prove things about safe access to global
> variables.  If the RM allowed parallel evaluation of parameter expressions,
> all of the discussion in RM95 9.10 about sharing variables between tasks and
> about "independent addressability" would have to apply to sharing variables
> and manipulating neighboring packed-array components between different
> parameter evaluations, which would dramatically increase the likelihood
> of erroneous execution per 9.10(11).
>
> See RM95 9.10 for a discussion of these issues.  The critical paragraph
> is 9.10(13), where any two actions that occur as part of the execution
> of a single task are defined to be "sequential."  In some ways, that
> *is* the definition of a "task."
>
> : --
> : T.E.D.
>
> --
> -Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
> Intermetrics, Inc.  Burlington, MA  USA
>


Note that in one respect Ada went MUCH too far, and that is
the decision that for a binary operator you must evaluate
either left-then-right, or right-then-left.

While I don't think anyone would argue for the collateral
(parallel) evaluation semantics of Algol-68 in a language
with side effects, it is still annoying that in

  (f + g) + (h + i)

where f,g,h,i are function calls, that

f/g/h/i
g/f/h/i
f/g/i/h
g/f/i/h
h/i/f/g
h/i/g/f
i/h/f/g
i/h/g/f

are all permitted orders, but no other orders (e.g.

f/h/g/i

are permissible. This seems to me to be silly over
specification. Note that it is very hard to construct
an example where this matters (and even the ACVC tests
do not test for this).

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Software landmines (was: Why C++ is successful)

[Matthew Heaney]

dewarr@my-dejanews.com writes:

> > > > declare
> > > >    A : Integer renames Get_A (10);
> > > >    B : Float renames Get_B (X);
> > > >    C : Boolean renames Get_C (Y);
> > > > begin
> > > >    Op (A, B, C);
> > > > end;

> I must say that I find the renaming of function calls
> like this to be a confusing oddity. It seems much clearer
> to me to use ordinary constant declarations. The two
> seem completely equivalent!

Funny, since using Ada95, I always use "renames" in preference to
"constant T :=".
 
One difference is that renames is available for limited types:

declare
   File : File_Type renames Standard_Output;
begin

This nicely emphasizes that this isn't assignment: it's a binding of a
name to an object, which is completely different, and justifies the
different syntax.

For a while now I've felt that Ada really got the concept of
initialization all wrong.  Dijkstra speaks to the issue in Chap 10, An
Essay on the Notion: "The Scope of Variables" in his book A Displine of
Programming:

(start of quote) Upon second thought it seems only honest to use
different notations [for initialization and assignment], for they are
very different operations: while the initializing statement is in a
sense a creative one (it creates a variable with an initial value), the
true assignment statement is a destructive one in the sense that it
destroys information, viz. the variable's former value. (end of quote)

He hit the nail right on the head.  The problem with Ada is that it
blurs the distinction between initialization and assignment, especially
since it uses the assignment operator in a constant declaration.

(Although even Dijkstra used the assignment operator in his declarations.
The only difference is that he marks initialization with the keyword
"vir" (for "virgin"), and Ada marks it using "constant".)

Robert, you pointed out in an earlier post how many programmers "misuse
assignment."  This is confirmed by my own experience.  However, if many
programmers do the wrong thing wrt a specific language construct, then
that may indicate something is wrong with the language itself, and not
with the programmers.

The use of the assignment operator where initialization is intended
tends to inculcate the idea that there really isn't any difference.
This is unfortunate.

One obvious problem with the Ada approach is that limited objects can't
be initialized during their declaration (except for default
initialization, of course).  Better would have been true constructor
operations, with a different syntax.  In the past I've suggested
something like:

declare
   File : File_Type'Open ("matt.dat", In_File);
begin

so that no assignment operator is required in order to do
initialization.

Unfortunately, not being able to initialize a limited object during its
elaboration means that there's a zone between the object declaration and
object initialization, in which the state of the object may be
undefined.  (Or only defined via what's possible using default
initialization - but that kind of initialization isn't very interesting
or useful.)

It also means if I build up a value in a declarative region, via a
series of constant declarations, then when I reach the declaration of a
limited object, I have to stop the declarative region, since I can't use
the limited object until I've initialized it, which doesn't occur until
the start of the exectuble region.  This is a real bummer, since I have
to create variables when constants would do.

The assignment operator in Ada is very confusing still, because I can
use it as a renames operator for a limited object that's a default
parameter:

  procedure Op (File : File_Type := Standard_Output);

Very confusing indeed, since the assignment operator is clearly not
being used for assignment!  I'm all for language parsimony, but this
overloading of the assignment operator is only going to confuse
neophytes.

So if I seem inclined to use a renames clause when the language allows
me to use assignment operator, it's because I'm trying to emphasize that
the declaration has the sense of a binding operation, and to
de-emphasize any notion of assignment.

When I look at the constant declaration

declare  
   A : constant Integer := Get_A (...);
begin

I really have to cringe, since it looks so much like an assignment.

Thinking about it more, I think that Ada unnecessarily exposed the fact
that an entity is a constant object, when all a client really cares
about is that it's a name bound to a value.  It would have been hipper
if the language allowed this to be hidden somehow, so that only the
implementator of an abstraction has to know that the return value is
really a constant object.

It would also be more consistent with other syntactic constructs that
bind a name to a value:

package P is ...
   binds the name P to a package.

procedure Op (...) is ...
   binds the name Op to a procedure.

type T is ...
   bind the name T to a type.

-but-

declare
   A : constant Integer := ...;
begin   
   binds the name A to a value???

Why not a uniform syntax:

declare
   A : Integer is ...;
begin

or maybe

declare
   value A : Integer is ...;

Using renames comes close to being able to do that:

declare
   A : Integer renames ...;
begin

It's sort of a bummer that we have two different keywords (renames vs
is) to do binding.

But the language problem we really need to solve is array
initialization.  For example, it's sometimes required to have array
components whose state is a function of their index value.  

If the array components are limited, then there's no simple way to do
that (say, to pass in the index value as the discriminant of a task
object, to serve as its Id), except by using two array declarations and
indirection.

One idea I had is something like:

   task type Task_Type (Id : Positive) is ...;

   type Array_Type is 
      array (Positive range <>) of Task_Type;

declare
   O : Array_Type (1 .. N)'(for I in O'Range O(I));
begin

You could even invoke a constructor using this syntax:

   type CT is ...;

   constructor CT'Initialize (Index : Positive);

   type T is array (Positive range <>) of CT;

declare
   O : T (1 .. N)'(for I in O'Range O(I)'Initialize (I));
begin