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)

[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)

[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)

[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)

[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:

> >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)

[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)

[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)

[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)

[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 <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

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: Why C++ is successful

[Robert Dewar]

Lars says

<<Are you saying tht GC would introduce a larger risk for incorrect
programs than exceptions? If so, why?
>>

Most certainly! GC introduces a huge risk for incorrect programs. Garbage
collectors assume that the pointer structure of a program is correct. If
it is corruptede, garbage collectors can cause horrible havoc. Indeed this
havoc often only shows up after several mark-and-sweep type cycles of the
GC, and it can be almost impossible to track them down

(said from horrible experiences in implementing general GC!)

Re: Why C++ is successful

[harald.mueller]

In article <dewar.902415458@merv>,
  dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
>
> Lars says
>
> <<Are you saying tht GC would introduce a larger risk for incorrect
> programs than exceptions? If so, why?
> >>
>
> Most certainly! GC introduces a huge risk for incorrect programs. Garbage
> collectors assume that the pointer structure of a program is correct. If
> it is corruptede, garbage collectors can cause horrible havoc. Indeed this
> havoc often only shows up after several mark-and-sweep type cycles of the
> GC, and it can be almost impossible to track them down
>
> (said from horrible experiences in implementing general GC!)
>

Now that's interesting. I did never write a GC, but I wrote a heap management
system, which had bugs in it for the first few weeks, and you wouldn't
believe it: A correct GC would have been MUCH BETTER than my wrong heap
management. So?

Actually, the problem with new/delete schemes is that the *user*(!!) can
corrupt the heap, e.g. by deleting stack variables:

f(C* p) {
   C defaultC;
   C* c;
   if (p == null) c = &defaultC;
   else c = p;
   ...
   ...
   ...
   delete c;
}

Similar with static class variables etc. You wouldn't believe how many heaps
silently and very late crash after such errors (which are mostly introduced
innocently during maintenance - "we dont have to create a new C all the time -
just let's have a single static one").

HMMueller

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

Re: Why C++ is successful

[Brian Rogoff]

On Fri, 7 Aug 1998 harald.mueller@siemenscom.com wrote:
>   dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
> > Most certainly! GC introduces a huge risk for incorrect programs. Garbage
> > collectors assume that the pointer structure of a program is correct. If
> > it is corruptede, garbage collectors can cause horrible havoc. Indeed this
> > havoc often only shows up after several mark-and-sweep type cycles of the
> > GC, and it can be almost impossible to track them down
> >
> > (said from horrible experiences in implementing general GC!)
> 
> Now that's interesting. I did never write a GC, but I wrote a heap management
> system, which had bugs in it for the first few weeks, and you wouldn't
> believe it: A correct GC would have been MUCH BETTER than my wrong heap
> management. So?

I have nothing against GC, in fact I like it in general and wish its use
was more widespread, but a very large part of your problem is that the
language you are working in 

(1) Doesn't distinguish between pointers to local variables and pointers 
    to heap allocated memory.

(2) Allows you to get a pointer to any local variable, rather than forcing 
    you to be explicit about which local variables can be pointed to, or 
    "aliased". 

(3) Makes it easy to do all kinds of other arbitrary weird things with
    pointers. 

In an otherwise very similar language, Ada, none of these are a problem. 
Sure, the user could always declare every local variable as aliased, and 
make every pointer "access all" to point to heap and local variables, and 
insist on using Unchecked_Access ("&" in C/C++) and Unchecked_Conversion 
(casting) to turn off all the checks, but the presence of "Unchecked_" 
anything tells you where the problem might be. Modula-3 has the
requirement that any module which uses unsafe features of the language 
be labelled as UNSAFE, which is an idea I like too, though it also has 
GC so you proabbly wouldn't write allocators in M3. 

I tend to think of Ada as being semantically similar to C++ (especially
wrt to the fact that Ada allows low level programming), except that 
while C++ allows you to be safe, the defaults are unsafe, and while 
Ada allows you to be unsafe, the defaults are safe. Since I'm sort of a 
slapdash programmer, I prefer help from the compiler to avoid the sort of 
mishaps Harald describes. Doubtless the C++ experts out there who are
writing reliable code are a lot smarter than me and don't need this kind
of help, or they get it by using tools like Lint and Purify; probably
both. I don't have the same problems in Ada that I do in C or C++, even 
though I'm *far* more familiar with C than Ada (I use C every day).

-- Brian

Re: Why C++ is successful

[Timothy Welch]

On Fri, 7 Aug 1998 13:21:17 -0700, Brian Rogoff
<bpr@shell5.ba.best.com> wrote:

>I have nothing against GC, in fact I like it in general and wish its use
>was more widespread, but a very large part of your problem is that the
>language you are working in 
>
>(1) Doesn't distinguish between pointers to local variables and pointers 
>    to heap allocated memory.
>
>(2) Allows you to get a pointer to any local variable, rather than forcing 
>    you to be explicit about which local variables can be pointed to, or 
>    "aliased". 
>
>(3) Makes it easy to do all kinds of other arbitrary weird things with
>    pointers. 
>

Out of curiousity why are (1) and (2) problems? Can't the GC just
check to see if the pointer is pointing to memory on the stack?


Tim

Re: Why C++ is successful

[Robert Dewar]

Timothy Welch says

<<>(1) Doesn't distinguish between pointers to local variables and pointers
>    to heap allocated memory.
>
>(2) Allows you to get a pointer to any local variable, rather than forcing
>    you to be explicit about which local variables can be pointed to, or
>    "aliased".
>
>(3) Makes it easy to do all kinds of other arbitrary weird things with
>    pointers.
>

Out of curiousity why are (1) and (2) problems? Can't the GC just
check to see if the pointer is pointing to memory on the stack?
>>


Undoubtedly at least *part* of the problem in using C is that people are not
sufficiently aware of what can go wrong. Microsoft has a rather amazing
book that pretends to be a book about software techniques, but in fact is
little more than a set of perfectly standard coding procedures to avoid
pitfalls in C. When I read it, I was surprised that professional C 
programmers would find such a book useful, but the questions above are
a reminder that you often people are not aware of the dangers. I must
say I worry about CS curriculums in which people are only getting exposed
to C and C++ and hence simply don't register important language design
principles (after all the idea that it is obviously a bad idea to allow
pointers to local variables is a very old one, dating back at least to
Pascal, which means coming up to 30 years.

Timothy, to answer your questions.

(1) is a serious problem, since it can allow dangling pointers. That is,
when you leave a scope with such a pointer, then you have a pointer to
inactive stack. Using this pointer later on can cause serious damage, e.g.
clobbering a return point stored on the stack. These dangling pointers are
created even though you never use free. There is no practical implementation
mechanism for efficiently detecting such a dangling pointer.

(2) is of course related, but is at a more conceptual level. Aliasing is
always dangerous because it can cause code to be very difficult to read,
understand, and maintain (as well as leading to accidental bugs in the
first place). Consider in C:

	(everything is an int or a *int)

	a = b;
        c = 3 + q;
        *d = 4;
 
That assignment to *d *may* modify the values of a and c. This means you
cannot just read ahead in the code at this stage, you have to ensure that
it is not possible for d to be pointing to a or c, or worse discover that
it is possible, and that one of the first two assignments is dead.

A (good) compiler will make an attempt to determine the answer (it is not
always possible to do this reliably). A compiler that does not make this
effort risks generating horrible code for the above, since it has to forget
the values of a and c in registers. A compiler that tries hard still often
finds that it has to be conservative and assume the worst.

A (good) programmer will make an attempt to determine the answer (it is not
always possible to do this reliably). A programmer that does not make this
effort risks seriously misunderstanding the above, since they will have to
forget the assigned values of a and c. A programmer that tries hard still
often finds that they have to be conservative and assume the worst.

Note the parallel language here is quite deliberate. Whey you set obstacles
for a compiler, you set them for a programmer as well. A clever compiler
can compensate, and that's OK, since machine time is cheap, so what if the
compilation takes longer (but as noted, even a clever compiler can be fooled).
A clever programmer can compensate, and that is NOT OK, since programmer
time is not cheap, and maintenance mistakes are very costly.

In Pascal and Ada 83, a decision was made to completely disallow pointers
to local variables, and this is undoubtedly the best decision from a language
point of view.

However, especially when interfacing to other languages, this proves an
annoying restriction. For example, if you are interfacing to a language
like C that typically requires pointers to parameters to be passed, then
it is annoying not to be able to pass pointers to local variables. Ada 83
programmers would often resort to nasty low level junk (i.e. use of the
'Address attribute) for this purpose, leading to code that has all the
disadvantages discussed above, and more. Why more? Becuase (a) address gives 
untyped pointers, like void*, and (b) the semantics of whether the aliasing
attempt "works" correctly is not clear from the standard.

Ada 95 compromises by allowing you to declare a variable as aliased, which
means that it is allowable to take its "address", using the strongly typed
'Access attribute.

An Ada 95 program that declared every local variable to be aliased would be
equivalent to the C semantics (it would also be a travesty!)

Generally you should alias local variables ONLY in connection with interfacing
to foreign code. Yes, as with all rules, including this one, there are 
exceptions to this rule that are legitimate, but if you find you are using
aliased extensively, something may be wrong with your approach.

Robert Dewar

P.S. with respect to the GC part of your question, sure, you can determine
that a pointer points to the stack, but the dangling pointer case can cause
unimaginable chaos in a garbage collector. Indeed the combination of garbage
collection with semantics that allow dangling pointers is a dangerous one,
dangerous enough to make a language design quite dubious from a practical
point of view.

Re: Why C++ is successful

[Jeffrey C. Dege]

On 8 Aug 1998 08:27:02 -0400, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>
>Undoubtedly at least *part* of the problem in using C is that people are not
>sufficiently aware of what can go wrong. Microsoft has a rather amazing
>book that pretends to be a book about software techniques, but in fact is
>little more than a set of perfectly standard coding procedures to avoid
>pitfalls in C. When I read it, I was surprised that professional C 
>programmers would find such a book useful, but the questions above are
>a reminder that you often people are not aware of the dangers. 

If you're talking about Steve McGuire's books, (Code Complete, Writing
Solid Code), I'm a professional C programmer, and I didn't find anything
in them that I hadn't been aware of for many years.

>I must
>say I worry about CS curriculums in which people are only getting exposed
>to C and C++ and hence simply don't register important language design
>principles (after all the idea that it is obviously a bad idea to allow
>pointers to local variables is a very old one, dating back at least to
>Pascal, which means coming up to 30 years.

I have to agree with the above.  A CS curriculumn should have some breadth
to it.  Exposure to a variety of languages is a part of this, as is
instruction in the theory underlying compilers.

-- 
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" ("I found it!") but rather "hmm....that's
funny..."  --   Isaac Asimov

Re: Why C++ is successful

[Laurent GUERBY]

jdege@jdege.visi.com (Jeffrey C. Dege) writes:

> On 8 Aug 1998 08:27:02 -0400, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
> >
> >Undoubtedly at least *part* of the problem in using C is that people are not
> >sufficiently aware of what can go wrong. Microsoft has a rather amazing
> >book that pretends to be a book about software techniques, but in fact is
> >little more than a set of perfectly standard coding procedures to avoid
> >pitfalls in C. When I read it, I was surprised that professional C 
> >programmers would find such a book useful, but the questions above are
> >a reminder that you often people are not aware of the dangers. 
> 
> If you're talking about Steve McGuire's books, (Code Complete, Writing
> Solid Code), I'm a professional C programmer, and I didn't find anything
> in them that I hadn't been aware of for many years.
> [...]

   "Code Complete" author is Steve McConnell, not Steve McGuire.  I
think Robert talks about the latter.

   The former, "Code Complete", is a very nice book IMHO, and amongst
the languages covered there is Ada (together with C/C++/Pascal/VB).
It makes a nice advocacy package for strongly typed language BTW (you
can shoot yourself into the foot easily with language X whereas you
get an error message with language Y ;-).

   A little quote for c.l.a. readers, from the "goto" pro and cons
section (reminds me of some threads ;-):

"Finally, the goto was incorporated into the Ada language, the most
carefully engineered programming language in history. Ada was
developped long after the arguments on both sides of the goto debate
had been fully developped, and after considering all sides of the
issue, Ada engineers decided to include the goto"

-- 
Laurent Guerby <guerby@bnp-eng.remcomp.com>, Team Ada, Linux/GNU addict
   "Use the Source, Luke. The Source will be with you, always (GPL)."

Re: Why C++ is successful

[Andy Ward]

>   A little quote for c.l.a. readers, from the "goto" pro and cons
>section (reminds me of some threads ;-):
>
>"Finally, the goto was incorporated into the Ada language, the most
>carefully engineered programming language in history. Ada was
>developped long after the arguments on both sides of the goto debate
>had been fully developped, and after considering all sides of the
>issue, Ada engineers decided to include the goto"
>


Ahh... but have you ever found a "good" reason for using it? I have used
goto in C and Pascal in certain rare cases, but I have always found clearer
ways to code these cases in Ada.

Re: Why C++ is successful

[Robert Dewar]

Andy said

<<Ahh... but have you ever found a "good" reason for using it? I have used
goto in C and Pascal in certain rare cases, but I have always found clearer
ways to code these cases in Ada.
>>

The two obvious uses vfor gotos in Ada are

1) to get a loop "continue" mechanism

2) to write finite state machines encoding the state into the PC. Yes, some
people prefer case statements for this purpose, but many people prefer the
use of labels and gotos as the most obvious translation of labeled states
with arrows between them.

In general, the use of gotos makes sense if the resulting code is clearer
and easier to maintain. THat's relatively rare, but not non-existnent, and
it is quite common to run across tortured code with multiple boolean flags
which can be easily simplified using a goto. 

For example, I find the following perfectly clear:

   <<sort>> for J in 1 .. N - 1 loop
       if D (J) > D (J + 1) then
	  Swap (D(J), D(J + 1));
          goto Sort;
       end if;

It is a little tricky to program this without the goto and not make it
less clear. Actuallky many people who try this end up with a different
algorithm (hint: the above sort is cubic, it is NOT a quadratic bubble sort :-)
\x1adp

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

[dennison]

In article <dewar.903074236@merv>,
  dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
> Andy said
>
> <<Ahh... but have you ever found a "good" reason for using it? I have used
> goto in C and Pascal in certain rare cases, but I have always found clearer
> ways to code these cases in Ada.
> >>
>
> The two obvious uses vfor gotos in Ada are
>
> 1) to get a loop "continue" mechanism

for a simple loop, embedding the rest of the loop code in the body of the if
statement is clearer. For nested loops where you want to "continue" an outer
loop, I can see it. Not that I'd do such a thing. As a "goto-holic" who has
been straight for 10 years, the best bet is abstinence. One day at a time. :-)

> For example, I find the following perfectly clear:
>
>    <<sort>> for J in 1 .. N - 1 loop
>        if D (J) > D (J + 1) then
> 	  Swap (D(J), D(J + 1));
>           goto Sort;
>        end if;
>
> It is a little tricky to program this without the goto and not make it
> less clear. Actuallky many people who try this end up with a different
> algorithm (hint: the above sort is cubic, it is NOT a quadratic bubble sort
:-)

So the "average" poor maintainer schlep looks at this and thinks "is this
just a continue, or a complete restarting of the loop?" Oh yeah, that's
clear. %-(

If anyone does something this bizzare, they'd better put copious comments
around it explaining its semantics. Otherwise, its the software equivalent of
a land mine. Its just sitting there waiting for someone to touch it, then
...BOOM!

Very good counterexample to your own point.

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)

[Thaddeus L. Olczyk]

On Fri, 14 Aug 1998 14:13:10 GMT, dennison@telepath.com wrote:

>In article <dewar.903074236@merv>,
>  dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
>> Andy said
>>
>> <<Ahh... but have you ever found a "good" reason for using it? I have used
>> goto in C and Pascal in certain rare cases, but I have always found clearer
>> ways to code these cases in Ada.
>> >>
>>
>> The two obvious uses vfor gotos in Ada are
>>
>> 1) to get a loop "continue" mechanism
>
>for a simple loop, embedding the rest of the loop code in the body of the if
>statement is clearer. For nested loops where you want to "continue" an outer
>loop, I can see it. Not that I'd do such a thing. As a "goto-holic" who has
>been straight for 10 years, the best bet is abstinence. One day at a time. :-)
>
Most experienced C programmers will tell you that continue is just a 
glorified goto.

>> For example, I find the following perfectly clear:
>>
>>    <<sort>> for J in 1 .. N - 1 loop
>>        if D (J) > D (J + 1) then
>> 	  Swap (D(J), D(J + 1));
>>           goto Sort;
>>        end if;
>>
>> It is a little tricky to program this without the goto and not make it
>> less clear. Actuallky many people who try this end up with a different
>> algorithm (hint: the above sort is cubic, it is NOT a quadratic bubble sort
>:-)
Assuming I've read your code correctly, a better way would be

 for J in 1 .. N - 1 loop
      continue=true;	
        if D (J) > D (J + 1) then
 	  Swap (D(J), D(J + 1));
           continue=false;
        end if;
       if continue then

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

[Robert Dewar]

T.E.D says

  For a simple loop, embedding the rest of the loop code in the body
  of the if statement is clearer. For nested loops where you want to
  "continue" an outer loop, I can see it. Not that I'd do such a thing.

Even in the simple case:

   for J in 1 .. N loop
     if D (J) = NaN then
       goto Continue;
     end if;

     giant section of code

   <<Continue>> null;
   end loop;

as opposed to

   for J in 1 .. N loop
     if D (J) /= NaN then
        giant section of code
     end if;
   end loop;

there may be a preference for the goto. It shows the reader right up
front that the loop does nothing at all to NaN's, without having to
match up the if with the end if at the end of the giant section of
code to know this. Also, it means that the giant section of code
has one less level of indentation.

But it's a toss up in this case, and for most purposes we would prefer
the second case. Where it gets tricky is

   for J in 1 .. N loop
      if condition 1 then
         ...
         if condition 2 then
            ...
            if conditoin 3 then
               goto Continue;


Now T.E.D's prescription is not so clear, and we end up having to
severely contort things, or introduce a boolean flag which we keep
testing as we unwind to the end.

Remember that the continue here is just like a return. If you are allergic
to using a loop continue or exit, you should be allergic to using a return
(other than at the end of a function). Some people are, and that is at
least consistent. But I see a lot of Ada programmers who will use a return
without hesitation from a nested loop, but still turn green at the sight
of a goto. That makes no sense to me.

  As a "goto-holic" who has been straight for 10 years, the best bet
  is abstinence. One day at a time. :-)

Maybe the comparison is apt. If you really are unable to figure out how
to use gotos properly, then perhaps abstinence is the "best bet", but
just as we know that wine drunk in moderation can actually be a health
benefit, and is most certainly not a health danger, the occasional use
of a goto can be beneficial for the clarity and efficiency of your code.
We can appreciate and sympathize with the poor goto-holic's who may not
risk this, but it does not mean the rest of us have to abstain :-)


  So the "average" poor maintainer schlep looks at this and thinks
  "is this just a continue, or a complete restarting of the loop?"
  Oh yeah, that's clear. %-(

The idea that code can ever be maintained by incompetent shlep's who
do not understand the language they are writing in is of course a serious
error. Yes, I know it happens, look at the results, need I say more?

On the other hand, I see no reason to accept this rhetoric, if indeed
you do have these poor maintainer shleps looking at the code, we have
only T.E.D.'s unsupported allegation that they will have more trouble
with my form than some other form (note that, perhaps wisely, T.E.D
does not attempt to demonstrate the beautifully clear, alternative,
goto-free form -- enough other competent people have tripped on that
already :-)

  If anyone does something this bizzare, they'd better put copious
  comments around it explaining its semantics. Otherwise, its the
  software equivalent of a land mine. Its just sitting there waiting
  for someone to touch it, then ...BOOM!

Well of course any code needs commenting, and pointing out the critical
details of the algorithm in use, especially if, as in this case, it is
likely to be an unfamiliar algorithm, is definitely a good idea.

   Very good counterexample to your own point.

I don't think so!

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

[dennison]

In article <dewar.903281994@merv>,
  dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
> T.E.D says
>
> But it's a toss up in this case, and for most purposes we would prefer
> the second case. Where it gets tricky is
>
>    for J in 1 .. N loop
>       if condition 1 then
>          ...
>          if condition 2 then
>             ...
>             if conditoin 3 then
>                goto Continue;
>
> Now T.E.D's prescription is not so clear, and we end up having to
> severely contort things, or introduce a boolean flag which we keep
> testing as we unwind to the end.
>
> Remember that the continue here is just like a return. If you are allergic
> to using a loop continue or exit, you should be allergic to using a return
> (other than at the end of a function). Some people are, and that is at
> least consistent. But I see a lot of Ada programmers who will use a return
> without hesitation from a nested loop, but still turn green at the sight
> of a goto. That makes no sense to me.
>

Good point. Typically in this case I would "cheat" it and embed the inside of
the loop in a subprogram, with a return statement. You think that's no better
than using a "goto". I think it IS better, because the rule for where control
goes to after a return statement is much clearer than for goto. For the
return, I just start reading code after the subprogram call. For goto, I have
to search the entire source for the label that is being jumped to. Just as
importantly, someone can completely change my structure just by moving that
label. But yes, we are probably talking Bordeaux vs. Mad Dog 20-20.

>   So the "average" poor maintainer schlep looks at this and thinks
>   "is this just a continue, or a complete restarting of the loop?"
>   Oh yeah, that's clear. %-(
>
> On the other hand, I see no reason to accept this rhetoric, if indeed
> you do have these poor maintainer shleps looking at the code, we have
> only T.E.D.'s unsupported allegation that they will have more trouble
> with my form than some other form (note that, perhaps wisely, T.E.D
> does not attempt to demonstrate the beautifully clear, alternative,
> goto-free form -- enough other competent people have tripped on that
> already :-)

Why take my word for it? The very fact that "other competent people have
tripped on that" proves how obtuse it is. You'd be quite lucky to have a
maintanence staff as good as the folks here on c.l.*, and *they* can't even
make a simple change to your code without completely screwing it up. I
couldn't hope to come up with a better example.

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)

[adam]

In article <6r9f8h$jtm$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> In article <dewar.903281994@merv>,
>   dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
> > T.E.D says
> >
> > But it's a toss up in this case, and for most purposes we would prefer
> > the second case. Where it gets tricky is
> >
> >    for J in 1 .. N loop
> >       if condition 1 then
> >          ...
> >          if condition 2 then
> >             ...
> >             if conditoin 3 then
> >                goto Continue;
> >
> > Now T.E.D's prescription is not so clear, and we end up having to
> > severely contort things, or introduce a boolean flag which we keep
> > testing as we unwind to the end.
> >
> > Remember that the continue here is just like a return. If you are allergic
> > to using a loop continue or exit, you should be allergic to using a return
> > (other than at the end of a function). Some people are, and that is at
> > least consistent. But I see a lot of Ada programmers who will use a return
> > without hesitation from a nested loop, but still turn green at the sight
> > of a goto. That makes no sense to me.
> >
>
> Good point. Typically in this case I would "cheat" it and embed the inside of
> the loop in a subprogram, with a return statement. . . .

I've been thinking about a similar problem that I keep running into, where
you execute a sequence of statements, and after many of the statements, you
have to make some test to ensure that the statement was successful or that
your pointers aren't null or that you don't have garbage data or something
like that.  I don't like code like

    blah-blah-blah;
    if not error-condition-1 then
        keep-going;
        if not error-condition-2 then
            still-keep-going;
            if not error-condition-3 then
                 everythings-still-fine-keep-going;
                 etc.

because it's hard to read unless you have a terminal that's shaped like a
parallelogram.  Also, if you keep this up, you end up being able to put only
30 characters on a line, and it takes 3 lines to code one Ada statement.

Having a flag that you keep testing is one alternative.  So is "goto".  So
is T.E.D's workaround of putting the code in a subprogram and using "return".
So is defining a local exception:

    declare
        error : exception;
    begin
        blah-blah-blah;
        if error-condition-1 then raise error; end if;
        keep-going;
        if error-condition-2 then raise error; end if;
        still-keep-going;
        if error-condition-3 then raise error; end if;
        everythings-still-fine-keep-going;
        etc.
    exception
        when error => ...
    end;

Question: Would you expect the compiler to optimize the "raise error" to a
simple branch to the exception handler in this case, assuming the exception
handler didn't contain any statements that depended on Ada's exception
features?

Note that I think using a local exception is an option *only* because the
thing I'm testing for is an error condition; it wouldn't be appropriate for
most other types of conditions.

Anyway, here's my main question:  Is it desirable to expand the syntax of
"exit" to cover cases like this?  I think it might be nice.  I'm thinking that
code like this could look something like:

    block_to_do_stuff:
    begin
        blah-blah-blah;
        exit block_to_do_stuff when error-condition-1;
        keep-going;
        exit block_to_do_stuff when error-condition-2;
        still-keep-going;
        exit block_to_do_stuff when error-condition-3;
        everythings-still-fine-keep-going;
        etc.
    end block_to_do_stuff;

I think one of the Ada 9X proposals actually had a feature like this, but
unfortunately it also changed the semantics of "exit" in a way that would
change the meanings of a lot of Ada 83 code.  Probably, that's why it was
dropped from the final Ada 95 definition.  But I think that the exit-block
feature in my example would be a very useful addition to the next version
of Ada.  (I'd define it so that this use of "exit" requires a block name,
so that the semantics of "unnamed" exit statements are unchanged; that way,
there wouldn't be any upward compatibility problems.)

So do the rest of you think it's a useful enough feature to consider adding
to Ada?

				-- Adam

-----== 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]

adam@irvine.com wrote:
: ...
: Anyway, here's my main question:  Is it desirable to expand the syntax of
: "exit" to cover cases like this?  I think it might be nice.  I'm thinking that
: code like this could look something like:

:     block_to_do_stuff:
:     begin
:         blah-blah-blah;
:         exit block_to_do_stuff when error-condition-1;
:         keep-going;
:         exit block_to_do_stuff when error-condition-2;
:         still-keep-going;
:         exit block_to_do_stuff when error-condition-3;
:         everythings-still-fine-keep-going;
:         etc.
:     end block_to_do_stuff;

: I think one of the Ada 9X proposals actually had a feature like this, but
: unfortunately it also changed the semantics of "exit" in a way that would
: change the meanings of a lot of Ada 83 code.  Probably, that's why it was
: dropped from the final Ada 95 definition.  

The Ada 9x proposal was "upward consistent" in that it didn't change the 
meaning of any existing programs to a new legal meaning, but it did make 
some of them illegal (those that involved exits from blocks nested in loops,
I believe).

: ... But I think that the exit-block
: feature in my example would be a very useful addition to the next version
: of Ada.  (I'd define it so that this use of "exit" requires a block name,
: so that the semantics of "unnamed" exit statements are unchanged; that way,
: there wouldn't be any upward compatibility problems.)

We also considered this proposal.  Basically, we couldn't find a
"clean" solution that looked like it wasn't just an add-on rather
than something built in from the beginning.  Also, the problem being
solved is relatively minor, and we had bigger fish to fry (mix those
metaphors liberally, please).

: So do the rest of you think it's a useful enough feature to consider adding
: to Ada?

If there were a solution that treated loops and blocks symmetrically,
that would be nice.  But a proposal that only allows exiting from
unnamed loops, while disallowing exiting from unnamed blocks, is
a kludge.  I would prefer something which allowed an unnamed "exit" to be
legal only if there were exactly one block or loop enclosing the point.
If there were more than one, then the exit would have to be named.
This way, adding another level of block or loop to an existing program with
an unnamed exit would never result in an exit going to the wrong place,
but it might result in the program becoming illegal.  This avoids a kind
of "Beaujolais" effect for unnamed exit statements (the "Beaujolais" 
effect is a case where adding or removing a declaration from a "used"
package would change the meaning of a program from one legal interpretation
to another -- Ada 95 doesn't have them, Ada 83 had very few (all obscure),
"used" C++ namespaces have them for sure).

The general Ada principle is to require that the programmer write more
if that will help to make the meaning clear to the reader.  (Note that
sometimes writing *less* makes things clearer to the reader.
The key is to keep the signal to noise ratio high.)  

Unnamed exits should be limited to cases where there is no ambiguity, 
especially if they can exit multiple kinds of constructs.  The C situation is
bad news, where a "break" is used to exit both switch and loop,
and there is no "named" version of it.  I have seen plenty of bugs
where a break was meant to exit a loop, but really only exited the
nearest enclosing switch, or vice-versa.

: 				-- Adam

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

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

[adam]

In article <ExwxsA.EEL.0.-s@inmet.camb.inmet.com>,
  stt@houdini.camb.inmet.com (Tucker Taft) wrote:
> adam@irvine.com wrote:
> : ...
> : Anyway, here's my main question:  Is it desirable to expand the syntax of
> : "exit" to cover cases like this?  I think it might be nice.  I'm thinking
that
> : code like this could look something like:
>
> :     block_to_do_stuff:
> :     begin
> :         blah-blah-blah;
> :         exit block_to_do_stuff when error-condition-1;
> :         keep-going;
> :         exit block_to_do_stuff when error-condition-2;
> :         still-keep-going;
> :         exit block_to_do_stuff when error-condition-3;
> :         everythings-still-fine-keep-going;
> :         etc.
> :     end block_to_do_stuff;
>
> : I think one of the Ada 9X proposals actually had a feature like this, but
> : unfortunately it also changed the semantics of "exit" in a way that would
> : change the meanings of a lot of Ada 83 code.  Probably, that's why it was
> : dropped from the final Ada 95 definition.
>
> The Ada 9x proposal was "upward consistent" in that it didn't change the
> meaning of any existing programs to a new legal meaning, but it did make
> some of them illegal (those that involved exits from blocks nested in loops,
> I believe).

Not just blocks--I think compound statements were involved.  If my
recollection is correct, it would have made the following code illegal:

    for I in Arr'Range loop
        if Arr (I) = Search_Value then
            Found_Index := I;
            exit;      <==== illegal according to 9X draft
        end if;
    end loop;

But I do remember now that this would have been illegal and not legal with a
different meaning.  As I recall, I did a grep through the code of my main
project for "exit;" (which would have always been illegal under this
proposal---the proposed syntax did not allow for "exit" all by itself) and
found it occurred about a hundred times.  I thought this was pretty obnoxious.


> If there were a solution that treated loops and blocks symmetrically,
> that would be nice.  But a proposal that only allows exiting from
> unnamed loops, while disallowing exiting from unnamed blocks, is
> a kludge.  I would prefer something which allowed an unnamed "exit" to be
> legal only if there were exactly one block or loop enclosing the point.

Actually, this would make a lot of sense to me.  I think I tend to do this
anyway when two loops are nested, but I'd have to look through my code to
make sure.  I'd support a proposal like this; the amount of previously legal
code that would be made illegal would be IMHO *much* less than the dropped
9X proposal did.

I also agree that this is a minor problem.  I'm willing to add this case to
the short list of situations where "goto" is appropriate.  Now all I have to
do is go against all my training and allow that 4-letter word into my code.
Easier said than done.  :)

				-- Adam

-----== 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)

[ell]

In article <6r9f8h$jtm$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> In article <dewar.903281994@merv>,
>   dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
> > T.E.D says
> >
> > But it's a toss up in this case, and for most purposes we would prefer
> > the second case. Where it gets tricky is
> >
> >    for J in 1 .. N loop
> >       if condition 1 then
> >          ...
> >          if condition 2 then
> >             ...
> >             if conditoin 3 then
> >                goto Continue;
> >
> > Now T.E.D's prescription is not so clear, and we end up having to
> > severely contort things, or introduce a boolean flag which we keep
> > testing as we unwind to the end.
> >
> > Remember that the continue here is just like a return. If you are allergic
> > to using a loop continue or exit, you should be allergic to using a return
> > (other than at the end of a function). Some people are, and that is at
> > least consistent. But I see a lot of Ada programmers who will use a return
> > without hesitation from a nested loop, but still turn green at the sight
> > of a goto. That makes no sense to me.

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'.

Elliott

-----== 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)

[adam]

In article <6renh8$ga7$1@nnrp1.dejanews.com>,
  ell@access.digex.net wrote:

> 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, to me this seems to be a huge advantage of "return" over "using too many
goto's in your code that go every which way so that your code ends up looking
like spaghetti."  No one is supporting the idea of using that many goto's,
the way programmers used to.  Those who think goto's are OK think they should
be limited to certain specific situations, and your objection really doesn't
apply when goto's are used in that sort of careful, disciplined fashion.  Of
course, "goto" can be dangerous in the hands of an inexperienced programmer;
but so, for that matter, can every other construct of every language.

In the 22 years or so since programmers have started treating "goto" as an
evil, I've seen some pretty strange arguments purporting to explain *why*
goto's were bad.  The most bizarre one I've seen argued that if your code is
structured as follows:

         Transformation-1;  goto L;  Transformation-2;  L: ....

where Transformation-1 and Transformation-2 are sequences of statements or
something else that transform your current program state from one thing to
another, then the presence of "goto" in effect means that your code contains
the inverse function of Transformation-2, which cancels the effect of
Transformation-2.  The author offered this as an explanation why "goto" makes
code harder to understand.  I don't remember exactly where I read this, but it
was in one of the ACM publications.

Of course, this is nonsense.  There are good reasons why a researcher might
want to think of a "program" as a sequence of mathematical transformations on
the program state, but an ordinary programmer trying to write correct code,
or to read or maintain someone else's code, isn't going to think about things
that way.  That's why I'm skeptical about most of the arguments I see about
why GOTO IS EVIL.  There often seems to be an implicit assumption that
mathematical purity, or an aesthetically beautiful program structure, or
something similar, equals readability, but that isn't the case.  So when I
see statements like "'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", my reaction is, "So what?"  This argument contains no
explanation *why* this makes programs harder to work with.

So, personally, I think arguments against "goto" (or against any other
construction) should demonstrate things from the programmer's point of view.
That is, how does this EVIL NASTY construct actually make it harder for a
programmer to understand what's going on, or make it easier for a programmer
to miss something and write incorrect code?  If the argument doesn't address
the issue from that angle, it's worthless, IMHO.

Now, here are a couple arguments on the other side:

(1) Say you want to avoid the EVIL NASTY "goto" by putting the code into a
subroutine and using "return".	Well, you have to give the subroutine a name.
In place of the nested "if" causing the problem, you'll have a call to this
subroutine.  Now, when a programmer looks through the main line of code,
she'll see a call to this subroutine, and she'll have to know what it does. 
Can you give the subroutine a name that will make it obvious to the
maintenance programmer what's going on?

Sometimes you can.  But if all you're doing is extracting some code and
sticking it in a subroutine, most of the time you can't give it a good
descriptive name, since it reflects just a random sequence of statements and
not a concept that can be easily compartmentalized.  So in this case, IMHO
doing this is worse than using "goto", since it makes the program less clear.
 Of course, you can probably figure out a way to redesign the code to make it
clear, and your code will be more readable since it has smaller, more compact
subroutines that perform a well-defined purpose.  But this just illustrates
the importance of good design in general; a programmer who simply says
"RETURN is a lot better than GOTO" and moves code around just to avoid the
GOTO is unlikely to end up with a more readable and maintainable program.

(2) (This one is about "continue", since Charles Hixson later argued that this
was also superior to "goto" for the same reasons.)  If you have a loop that
looks like:

     while (blah-blah) {
          some-if-statements...
          some-more-if-statements...

          xxx;
          yyy;
          zzz;
     }

someone reading the program might assume that xxx, yyy, and zzz are always
going to happen before the loop repeats.  So if there's something new that
needs to be done during every loop iteration, it looks like you can just add
it to the end of the loop, after zzz.  If there's a "continue" statement
somewhere above that, this assumption is incorrect and your modification may
well be wrong.	If you replace the "continue" with a "goto", at least there
will be a label somewhere toward the bottom of the loop, alerting you to the
fact that you will have to decide whether to put the new code before or after
the label, or look for the place where this label is goto'ed.  In fact, this
is exactly why I stopped using "continue" when I was a C programmer.  (I
didn't replace them with goto's, I used Boolean flags instead.)

Now all of this may be a matter of how each individual programmer tends to
think when they look at programs.  The point is that, based on my experience,
arguments about "returning to where the linear control flow was diverted" and
"restricted compass" don't make a whole lot of sense in the real world.  GOTO
can be used in ways that enhance readability or in ways that impair it, and
so can every other feature of every language.

				-- Adam

-----== 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)

[Dan Higdon]

adam@irvine.com wrote in message <6rf59b$2ud$1@nnrp1.dejanews.com>...

<snip prelude>

>Now, here are a couple arguments on the other side:

<snip point 1>


>(2) (This one is about "continue", since Charles Hixson later argued that
this
>was also superior to "goto" for the same reasons.)  If you have a loop that
>looks like:
>
>     while (blah-blah) {
>          some-if-statements...
>          some-more-if-statements...
>
>          xxx;
>          yyy;
>          zzz;
>     }
>
>someone reading the program might assume that xxx, yyy, and zzz are always
>going to happen before the loop repeats.  So if there's something new that
>needs to be done during every loop iteration, it looks like you can just
add
>it to the end of the loop, after zzz.  If there's a "continue" statement
>somewhere above that, this assumption is incorrect and your modification
may
>well be wrong. If you replace the "continue" with a "goto", at least there
>will be a label somewhere toward the bottom of the loop, alerting you to
the
>fact that you will have to decide whether to put the new code before or
after
>the label, or look for the place where this label is goto'ed.  In fact,
this
>is exactly why I stopped using "continue" when I was a C programmer.  (I
>didn't replace them with goto's, I used Boolean flags instead.)

So, you've actually changed the algorithm of your code, added an unnecessary
data item and added yet another compare/branch to avoid a well understood
(IMHO) construct of the C language?  Perhaps I'm the only one who thinks
writing
code that will execute efficiently is equally important as writing readable
code.
If I didn't care about efficiency, I sure wouldn't be using a 3rd generation
procedural
language (OO or not) - there are (IMHO) many more succinct and
mathematically
rigorous languages out there than C or Eiffel (ML and Haskell come to mind,
niether of which have gotos, fwiw).

I'm not trying to start a language war - I'm pointing out that gotos and the
implicit
goto forms (break, continue, etc) are a tool of the language.  They wouldn't
be
there if you NEVER needed them.  So if you have a case that warrants their
use,
you should use them, rather than trying to hamstring yourself with hokey
constructs.
If you *need* that boolean value later, then by all means add it.  But I
think that
using a boolean flag to erase a GOTO is not contributing to the solution,
just
adding inefficiency into the generated code, and one more symbol for the
programmer to have to track.

----------------------------------------
hdan@charybdis.com
"Throwing fire at the sun"

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

[adam]

In article <l5HC1.6840$wN.1856764@news.giganews.com>,
  "Dan Higdon" <hdan@charybdis.com> wrote:

>
> adam@irvine.com wrote in message <6rf59b$2ud$1@nnrp1.dejanews.com>...
>
> <snip prelude>
>
> >Now, here are a couple arguments on the other side:
>
> <snip point 1>
>
> >(2) (This one is about "continue", since Charles Hixson later argued
> >that this was also superior to "goto" for the same reasons.)  If
> >you have a loop that looks like:
> >
> >     while (blah-blah) {
> >          some-if-statements...
> >          some-more-if-statements...
> >
> >          xxx;
> >          yyy;
> >          zzz;
> >     }
> >
> >someone reading the program might assume that xxx, yyy, and zzz are
> >always going to happen before the loop repeats.  So if there's
> >something new that needs to be done during every loop iteration, it
> >looks like you can just add it to the end of the loop, after zzz.
> >If there's a "continue" statement somewhere above that, this
> >assumption is incorrect and your modification may well be wrong. If
> >you replace the "continue" with a "goto", at least there will be a
> >label somewhere toward the bottom of the loop, alerting you to the
> >fact that you will have to decide whether to put the new code
> >before or after the label, or look for the place where this label
> >is goto'ed.  In fact, this is exactly why I stopped using
> >"continue" when I was a C programmer.  (I didn't replace them with
> >goto's, I used Boolean flags instead.)
>
> So, you've actually changed the algorithm of your code, added an
> unnecessary data item and added yet another compare/branch to avoid
> a well understood (IMHO) construct of the C language?  Perhaps I'm
> the only one who thinks writing code that will execute efficiently
> is equally important as writing readable code.  If I didn't care
> about efficiency, I sure wouldn't be using a 3rd generation
> procedural language (OO or not) - there are (IMHO) many more
> succinct and mathematically rigorous languages out there than C or
> Eiffel (ML and Haskell come to mind, niether of which have gotos,
> fwiw).

Well, I might have used GOTO if I had to do it over again.  My early
training taught me to avoid them, and this avoidance has become kind
of ingrained.  I still probably wouldn't use "continue", however.

However:

#1: Adding a flag in the manner I've described does not change the
algorithm, it merely changes the way the flow of control is expressed.
Unless you adopt a definition of "algorithm" that is so strict as to
be useless except to an academic.

#2: How important efficiency is depends on what you're writing.  If
you're working on time-critical code, it's very important, but if
you're working on an application where most of the program's time will
be spent waiting for the user to type in some input, a few hundred
microseconds isn't anything to worry about.

#3: A good optimizing compiler wouldn't do a compare/branch.  It might
set the flag, then notice that the next thing done is to test it, so
it would blow off the test and just branch to wherever the "continue"
statement was going to branch anyway.  An even better optimizing
compiler would then figure out that the flag is never actually tested,
so it would just get rid of it.

#4: Programmers don't always get to choose which language they use.

#5: In this thread, we're arguing about readability and
maintainability.  If you have a situation where every nanosecond is
critical, fine, but most of us are willing to give up a few
nanoseconds in order to save time debugging and maintaining programs.
If you've ever written a subroutine that was called at only one point
in the rest of the program, instead of coding it inline so that you
can avoid an unnecessary procedure call with all the stack pushes and
pops, then certainly you have to admit that readability is worth
sacrificing a couple machine cycles for, sometimes.


> I'm not trying to start a language war - I'm pointing out that gotos
> and the implicit goto forms (break, continue, etc) are a tool of the
> language.  They wouldn't be there if you NEVER needed them.

There are lots of language constructs that aren't really "needed".
And there are plenty of cases where an individual programmer, or a
programming department, adopts a policy of avoiding a particular
construct, which is fine as long as the prohibition isn't 100%
absolute.  A long time ago, I programmed in COBOL, and most of the
programmers around me agreed that the ALTER statement was just a bad
idea and shouldn't be used.  I'll bet few would disagree with such a
policy.

                                -- Adam

-----== 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)

[Dan Higdon]

adam@irvine.com wrote in message <6rfra4$rul$1@nnrp1.dejanews.com>...
>Well, I might have used GOTO if I had to do it over again.  My early
>training taught me to avoid them, and this avoidance has become kind
>of ingrained.  I still probably wouldn't use "continue", however.

Then you probably wouldn't object to something like (pseudocode, as I'm not
much of an Eiffel programmer):

loop
    if not <condition> then
        -- whole bunch of stuff
    end if
end loop

Instead?  That at least still only has you making the decision to branch
once,
instead of once when you set the flag and once when you decide what you
meant earlier.  I'll agree on the 'continue' avoidance, although I've found
that
constructs like that can make code a little cleaner if there is a whole lot
of
code in the "else" case.  (Probably putting that code into a separate
function
would make it even more clear. :-)

>However:
>
>#1: Adding a flag in the manner I've described does not change the
>algorithm, it merely changes the way the flow of control is expressed.
>Unless you adopt a definition of "algorithm" that is so strict as to
>be useless except to an academic.

You're checking the exit condition twice instead of once.  That's a little
like
saying that the 'k' term of a "Big O" analysis doesn't matter, IMHO.  It's
not
the meat of the algorithm, but it's definitely a detail.

>#2: How important efficiency is depends on what you're writing.  If
>you're working on time-critical code, it's very important, but if
>you're working on an application where most of the program's time will
>be spent waiting for the user to type in some input, a few hundred
>microseconds isn't anything to worry about.

 I probably shouldn't have come from a code efficiency standpoint - my
real objection is related to boolean flag usage.  If your algorithm demands
that you be able to remind yourself later about a condition, then by all
means.

As this relates to the topic:  I think that the use of boolean flags
strictly for local
flow control is a software landmine.  An unappreciated one (because so much
Pascal has been taught, and that's the only way to get Pascal to do some
things),
but a landmine none the less.


>#3: A good optimizing compiler wouldn't do a compare/branch.  It might
<snip>

I'm too suspicious of tool quality to rely on good compilers too much.

>#4: Programmers don't always get to choose which language they use.

Too true - I have to use C++.  Hence my fear of tool quality.  :-)

>#5: In this thread, we're arguing about readability and
>maintainability.  If you have a situation where every nanosecond is
>critical, fine, but most of us are willing to give up a few
>nanoseconds in order to save time debugging and maintaining programs.

Yes, I want to get back on topic as well - I agree that nanosecond timing
considerations and readable code don't always coexist peacfully.  Sadly,
it looks like we're getting into the subjective side of what is readable and
maintainable.  I find flags (local vars - not object data slots)
distracting.
Obviously you do not.  I guess we'll have to agree to disagree?

>There are lots of language constructs that aren't really "needed".
>And there are plenty of cases where an individual programmer, or a
>programming department, adopts a policy of avoiding a particular
>construct, which is fine as long as the prohibition isn't 100%

I'll agree with that - we don't use exceptions (time sensitivity issues) or
templates (bad compiler support) in our C++ code usually, but sometimes
a template is the best way to do something.  (But don't get me started
on the STL - one of the most compelling reasons to switch away from C++
yet, IMHO.)

>absolute.  A long time ago, I programmed in COBOL, and most of the
>programmers around me agreed that the ALTER statement was just a bad
>idea and shouldn't be used.  I'll bet few would disagree with such a
>policy.

I've not had the pleasure(?) of programming in COBOL - FORTRAN was my
teething ring.  But I suspect ALTER is about as much fun to maintain as an
arithmatic IF statement.  :-)

----------------------------------------
hdan@charybdis.com
"Throwing fire at the sun"

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

[Frank Adrian]

Matthew Heaney wrote in message ...
>A scanner is also another abstraction best implemented using gotos.

A scanner is a well enough defined abstraction with enough well constructed
(and fast) implementations around that anyone trying to write his own from
scratch should be censured.

[SNIP (of things that I agree with for the most part)]

>Use gotos when they make sense.  One time they do make sense is to
>implement a state machine, which requires transitions between states.
>This is typical for tasks and scanners.

Again, the tasks you mention should be subsumed by code generators or
higher-level design packages, not wasting programmers' time wondering if
they got the goto in (and pointing to) the right place.

Now the question is whether or not all "proper" uses of goto can be subsumed
by higher-level constructs (such as exception mechanisms, loop continuations
or breaks, etc.) which have much less of a cognative load than a fully
general and unstructured goto.  I tend to think so.
--
Frank A. Adrian
First DataBank

frank_adrian@firstdatabank.com (W)
franka@europa.com (H)

This message does not necessarily reflect those of my employer,
its parent company, or any of the co-subsidiaries of the parent
company.

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

[Robert I. Eachus]

In article <JTCG1.566$H52.143421@client.news.psi.net> "Frank Adrian" <frank_adrian@firstdatabank.com> writes:

 > Again, the tasks you mention should be subsumed by code generators or
 > higher-level design packages, not wasting programmers' time wondering if
 > they got the goto in (and pointing to) the right place.

   A fine point of view for an application developer.  But there are
those of us who build tools like compilers, scanner generators, parser
generators, etc.  Your code may not have gotos, and my code may not
have gotos, but when you use my tools to generate your code, don't be
surprised to find occasional (or not so occasional) gotos.



--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

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

[Biju Thomas]

Robert I. Eachus wrote:
> 
> In article <JTCG1.566$H52.143421@client.news.psi.net> "Frank Adrian" <frank_adrian@firstdatabank.com> writes:
> 
>  > Again, the tasks you mention should be subsumed by code generators or
>  > higher-level design packages, not wasting programmers' time wondering if
>  > they got the goto in (and pointing to) the right place.
> 
>    A fine point of view for an application developer.  But there are
> those of us who build tools like compilers, scanner generators, parser
> generators, etc.  Your code may not have gotos, and my code may not
> have gotos, but when you use my tools to generate your code, don't be
> surprised to find occasional (or not so occasional) gotos.

These tools may be generating gotos since they are decades old, and
nobody ever tried to improve upon them. 

Biju Thomas

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

[Robert Martin]

Biju Thomas wrote in message <35EB3B71.ED6D4066@ibm.net>...
>Robert I. Eachus wrote:
>>
>> In article <JTCG1.566$H52.143421@client.news.psi.net> "Frank Adrian"
<frank_adrian@firstdatabank.com> writes:
>>
>>  > Again, the tasks you mention should be subsumed by code generators or
>>  > higher-level design packages, not wasting programmers' time wondering
if
>>  > they got the goto in (and pointing to) the right place.
>>
>>    A fine point of view for an application developer.  But there are
>> those of us who build tools like compilers, scanner generators, parser
>> generators, etc.  Your code may not have gotos, and my code may not
>> have gotos, but when you use my tools to generate your code, don't be
>> surprised to find occasional (or not so occasional) gotos.
>
>These tools may be generating gotos since they are decades old, and
>nobody ever tried to improve upon them.

As long as the generated code does not have to be maintained, it doesn't
matter if it generates goto's or not.

Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (800) 338-6716 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

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

[Martin Dowie]

In article <6sfr1m$gi7$1@hirame.wwa.com>, Robert Martin
<rmartin@oma.com> writes
>
>Biju Thomas wrote in message <35EB3B71.ED6D4066@ibm.net>...
>>Robert I. Eachus wrote:
>>>
>>> In article <JTCG1.566$H52.143421@client.news.psi.net> "Frank Adrian"
><frank_adrian@firstdatabank.com> writes:
>>>
>>>  > Again, the tasks you mention should be subsumed by code generators or
>>>  > higher-level design packages, not wasting programmers' time wondering
>if
>>>  > they got the goto in (and pointing to) the right place.
>>>
>>>    A fine point of view for an application developer.  But there are
>>> those of us who build tools like compilers, scanner generators, parser
>>> generators, etc.  Your code may not have gotos, and my code may not
>>> have gotos, but when you use my tools to generate your code, don't be
>>> surprised to find occasional (or not so occasional) gotos.
>>
>>These tools may be generating gotos since they are decades old, and
>>nobody ever tried to improve upon them.
>
>As long as the generated code does not have to be maintained, it doesn't
>matter if it generates goto's or not.

absolutely - otherwise we'd be arguing against compilers/linkers
generating assembler language 'jump' statements
-- 
Martin Dowie

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

[Robert I. Eachus]

In article <35EB3B71.ED6D4066@ibm.net> Biju Thomas <bijuthom@ibm.net> writes:

 > These tools may be generating gotos since they are decades old, and
 > nobody ever tried to improve upon them. 

   NO!  Excuse the shouting.  If I am implementing your LALR(k)
grammar as a state machine, the only realization that makes sense is
to have hundreds of (sometimes thousands of) states.  I label the
states, and the code moves from state to state, recognizing that some
states shift information onto the stack, and others reduce the stack
(thus the old name of a shift-reduce parser).  The final program makes
spaghetti code look well organized, but the maintenance is done on the
grammer not on its realization.

   If you have a "more modern" tool, building the tables is just the
first step. Now your tool applies various transformations to the
tables which further complexify the resulting code. The resulting
compacted and optimized tables bear little or no resemblence to the
grammar, but the tables take a few thousand bytes of space, not a few
million, and the parser executes ten or so times as fast.  It is worth
the effort, but now the optimized grammar realization bears little
resemblence to the original parser output.  (To be more formal, the
parser generator might accept some superset of LALR(1) grammars as
input, and produce LR(1) tables as output.  The final optimized tables
may not be in LR(k) for any k.)

   The final representation (in machine code) is going to use jumps
and branches in any case.  But the code generated by the tool, if in a
high-level language can use a case statement or gotos.  Best however,
is to put addresses in the tables and have the state machine "table
driven."  Each state corresponds to executing the core of the driver
program with the address of the next state, and the stack as nominal
inputs.  This core can either be written as a procedure, or as just a
block of statements wrapped in a loop.  But what you end up with is a
driver program that is itself a realization of an FSM.  So far so
good, but this FSM must handle are several exceptional cases/states.
One is the final state, another is when due to the way the tables were
compressed, you want to return to a previous point in the processing.
(You reach the end of a table, but instead of an error, it says to
contine with another table--but you don't want to repeat the setup
code...)  The final case of course, is error handling.

    It usually turns out that when writing this driver program, you
can use loops, exception handling, continue statements, etc., to cover
all but one of the loop backs.  But much cleaner and clearer--and I
have written those driver programs in PL/I, Ada, and C--is to use one
or two well placed gotos.  A different way of stating it is that any
flowchart of the driver cannot be embedded in a plane.

    So we are back to where this discussion started.  There appear to
be some circumstances which justify use of gotos in Ada.  But the only
cases that anyone in this group has seen involve implementing finite
state machines of one kind or another.  I think that the structure
that makes gotos appropriate is exactly when the flowchart cannot be
embedded.   I'd like to find more cases if they exist.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

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

[dennison]

In article <EACHUS.98Sep1171449@spectre.mitre.org>,
  eachus@spectre.mitre.org (Robert I. Eachus) wrote:

> or two well placed gotos.  A different way of stating it is that any
> flowchart of the driver cannot be embedded in a plane.

..without flow lines crossing. Right?.

There's a mathematical way to express that, but my graph theory is too rusty
to come up with it now.

--
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)

[dewarr]

In article <JTCG1.566$H52.143421@client.news.psi.net>,
  "Frank Adrian" <frank_adrian@firstdatabank.com> wrote:
> Matthew Heaney wrote in message ...
> >A scanner is also another abstraction best implemented using gotos.
>
> A scanner is a well enough defined abstraction with enough well constructed
> (and fast) implementations around that anyone trying to write his own from
> scratch should be censured.
>
> [SNIP (of things that I agree with for the most part)]
>
> >Use gotos when they make sense.  One time they do make sense is to
> >implement a state machine, which requires transitions between states.
> >This is typical for tasks and scanners.
>
> Again, the tasks you mention should be subsumed by code generators or
> higher-level design packages, not wasting programmers' time wondering if
> they got the goto in (and pointing to) the right place.
>
> Now the question is whether or not all "proper" uses of goto can be subsumed
> by higher-level constructs (such as exception mechanisms, loop continuations
> or breaks, etc.) which have much less of a cognative load than a fully
> general and unstructured goto.  I tend to think so.
> --
> Frank A. Adrian
> First DataBank
>
> frank_adrian@firstdatabank.com (W)
> franka@europa.com (H)
>
> This message does not necessarily reflect those of my employer,
> its parent company, or any of the co-subsidiaries of the parent
> company.
>
>


The idea that writing your own scanner is a bad idea probably
shows simply a lack of awareness. The general tools available
for writing scanners generate extremely inefficient scanners
compared to what can be achieved if a scanner is specialized
to a particular language. In particular, the whole notion of
finite state machines is a red herring when it comes to
constructing efficient scanners for particular languages.

-----== 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)

[Jonathan Guthrie]

In comp.lang.ada Matthew Heaney <matthew_heaney@acm.org> wrote:
> I routinely use gotos to implement tasks.  Tasks usually execute a state
> machine, and gotos are the most natural way to implement the jumping
> between states that is required.

I have seen the assertion made that gotos are a natural way of handling
FSM's, and I have to mildly disagree with that statement.

I'm working on an industrial control system (well, it's industrial-style---
the system itself is intended to be installed at the fuelling positions in
automotive service stations) which consists of something like 2 dozen
programs running on 1+2N computers (where 'N' is the number of fuelling
positions) written in (so far) four different programming languages and
running under three different operating systems.

The set up is absolutely lousy with FSMs, but I can't use the PC to encode
the state because those programs that have FSMs have more than one.  (The
least I have in any is in the DS-5000 source, which has 3 FSMs in about
2000 lines of BASIC.)  I can't encode the state in the PC because I know
of no way of doing that (short of merging all of the state machines, which
is not possible due to memory constraints) when multiple independant finite
state machines exist in the same program.

I think I understand how to use it in scanners, though.  I hadn't realized
that it isn't necessary to save the state of the scanner (with the possible
exception of lookahead characters) when the scanner isn't active.  I would
have to check my sources to see if I've already built that assumption in
to my code.  (I'd be willing to bet that I have.  That seems to be the
difference between the FSMs I usually write and those independant ones I've
been building for Additech.)

Anyway, I would have to say that gotos are a natural way of handling some
FSMs, but not all.

-- 
Jonathan Guthrie (jguthrie@brokersys.com)
Information Broker Systems   +281-895-8101   http://www.brokersys.com/
12703 Veterans Memorial #106, Houston, TX  77014, USA

We sell Internet access and commercial Web space.  We also are general
network consultants in the greater Houston area.

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

[Ell]

adam@irvine.com wrote:

>In article <6renh8$ga7$1@nnrp1.dejanews.com>,
>  ell@access.digex.net wrote:
>
>> 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, to me this seems to be a huge advantage of "return" over "using too many
>goto's in your code that go every which way so that your code ends up looking
>like spaghetti."  No one is supporting the idea of using that many goto's,
>the way programmers used to.  Those who think goto's are OK think they should
>be limited to certain specific situations, and your objection really doesn't
>apply when goto's are used in that sort of careful, disciplined fashion.

My point is that 'return' applies a default discipline to 'goto'.  In
fact it's so useful that it now becomes OK to use 'return' quite
liberally.  This affords much flexibility.

>Of
>course, "goto" can be dangerous in the hands of an inexperienced programmer;
>but so, for that matter, can every other construct of every language.

I'm willing to use 'goto' in time critical code where inlines are not
possible, to save stack winding and unwinding.  Other than that I'd
rather use a procedure call and returns to get back.

Elliott
-- 
   :=***=:  Objective  *  Pre-code Modelling  *  Holistic  :=***=:
                 Hallmarks of the best SW Engineering
         "The domain object model is the foundation of OOD."
 Check out SW Modeller vs SW Craftite Central : www.access.digex.net/~ell
   Copyright 1998 Elliott. exclusive of others' writing. may be copied
     without permission only in the comp.* usenet and bitnet groups.

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

[Ell]

ell@access.digex.net (Ell) wrote:

>I'm willing to use 'goto' in time critical code where inlines are not
>possible, to save stack winding and unwinding.  Other than that I'd
>rather use a procedure call and returns to get back.

And even then, I try to organize the code so that I invoke 'goto
:labelX' and jump to its target ':labelX' **within** a single
procedure/function/module.

I try **never** to cross procedure/funtion/module boundaries with a
'goto', when I use it for time critical code.

Elliott
-- 
   :=***=:  Objective  *  Pre-code Modelling  *  Holistic  :=***=:
                 Hallmarks of the best SW Engineering
         "The domain object model is the foundation of OOD."
 Check out SW Modeller vs SW Craftite Central : www.access.digex.net/~ell
   Copyright 1998 Elliott. exclusive of others' writing. may be copied
     without permission only in the comp.* usenet and bitnet groups.

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

[John Goodsen]

Ell wrote in message <35dfb9a8.4685477@news.erols.com>...
>ell@access.digex.net (Ell) wrote:
>
>>I'm willing to use 'goto' in time critical code where inlines are not
>>possible, to save stack winding and unwinding.  Other than that I'd
>>rather use a procedure call and returns to get back.
>
>And even then, I try to organize the code so that I invoke 'goto
>:labelX' and jump to its target ':labelX' **within** a single
>procedure/function/module.
>
>I try **never** to cross procedure/funtion/module boundaries with a
>'goto', when I use it for time critical code.
>


It seems you are saying two things.  You use goto to save stack
winding/unwinding in time critical code, yet you never goto around
a "stack boundary" (e.g. a procedure/function boundary).

How do you use goto's to increase efficiency in these cases then?

thanks in advance,

--
John Goodsen          Saguaro Software, Inc. / Training & Consulting in:
jgoodsen@saguarosoft.com      - User Centered Systems Analysis
http://www.saguarosoft.com    - Object Oriented Architecture and Design
602.283.0142 / 888.298.2566   - Rapid Incremental Delivery S/W Process

"Example isn't another way to teach, it is the only way to teach. "
- Albert Einstein

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

[Ell]

"John Goodsen" <jgoodsen@saguarosoft.com> wrote:

>Ell wrote in message <35dfb9a8.4685477@news.erols.com>...
>>
>>ell@access.digex.net (Ell) wrote:
>>>
>>>I'm willing to use 'goto' in time critical code where inlines are not
>>>possible, to save stack winding and unwinding.  Other than that I'd
>>>rather use a procedure call and returns to get back.

>>And even then, I try to organize the code so that I invoke 'goto
>>:labelX' and jump to its target ':labelX' **within** a single
>>procedure/function/module.

>>I try **never** to cross procedure/funtion/module boundaries with a
>>'goto', when I use it for time critical code.

>It seems you are saying two things.  You use goto to save stack
>winding/unwinding in time critical code, yet you never goto around
>a "stack boundary" (e.g. a procedure/function boundary).

>How do you use goto's to increase efficiency in these cases then?

I don't.  I organize the relevant code - say for a sort - so that it
all resides within a single procedure/function/module.  I then
subdivide the code by preceding logical blocks with a 'labelX'.  And
then I use 'goto' to navigate from block to block.  

Typically, I end most blocks of code headed by a ':labelX' with a
'goto' that leads to the first line of code immediately after where
the 'goto' that entered the block was called.  E.g.

procedure xyz
{
	//  remember, code preceded by a ':labelX' must be entered
	//  by an explicit 'goto labelX' call.   it can *not* be entered by
	//  default "flow control fall through" with MSDOS batch files.

	xysytr
	wekll
	jhgjie
	goto label 1

	:label 2	//  label 2
	ceiue
	mhjyy
	return		//  exits procedure altogether

	:label 1	//  label 1
	lkjhgf
	touuy
	cnnfe
	goto label 2		// go back to next line after where this block
						// was called
};


In the above, the final block of code to be executed exits the
procedure with a 'return'

Of course you can make things more interesting with a conditional
constructs like 'if', 'case', or 'switch'.

procedure xyz
{
	xysytr
	wekll
	jhgjie
	goto label 2

	:label 2		//  label 2
	ceiue
	mhjyy
	goto label 3

	:label 3		//  label 3
	lkjhgf
	touuy
	cnnfe
	if x = 0
		goto label 2
	elseif x = 1
		goto label 4
	else
		return		//  leaves procedure 
	endif

	:label 4		// label 4
	hjuye
	mhyd
	lasdfl			//  procedure is left after this line
};

Elliott
-- 
   :=***=:  Objective  *  Pre-code Modelling  *  Holistic  :=***=:
                 Hallmarks of the best SW Engineering
         "The domain object model is the foundation of OOD."
 Check out SW Modeller vs SW Craftite Central : www.access.digex.net/~ell
   Copyright 1998 Elliott. exclusive of others' writing. may be copied
     without permission only in the comp.* usenet and bitnet groups.

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

[Ell]

ell@access.digex.net (Ell) wrote:

>	//  remember, code preceded by a ':labelX' must be entered
>	//  by an explicit 'goto labelX' call.   it can *not* be entered by
>	//  default "flow control fall through" with MSDOS batch files.

Rather:

>	//  remember, code preceded by a ':labelX' must be entered
>	//  by an explicit 'goto labelX' call.   it can *not* be entered by
>	//  default "flow control fall through" [like] MSDOS batch files.

^^^^

Elliott
-- 
   :=***=:  Objective  *  Pre-code Modelling  *  Holistic  :=***=:
                 Hallmarks of the best SW Engineering
         "The domain object model is the foundation of OOD."
 Check out SW Modeller vs SW Craftite Central : www.access.digex.net/~ell
   Copyright 1998 Elliott. exclusive of others' writing. may be copied
     without permission only in the comp.* usenet and bitnet groups.

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

[Larry Brasfield]

Ell wrote in message <35dfb9a8.4685477@news.erols.com>...
>ell@access.digex.net (Ell) wrote:
>
>>I'm willing to use 'goto' in time critical code where inlines are not
>>possible, to save stack winding and unwinding.  Other than that I'd
>>rather use a procedure call and returns to get back.
>
>And even then, I try to organize the code so that I invoke 'goto
>:labelX' and jump to its target ':labelX' **within** a single
>procedure/function/module.
>
>I try **never** to cross procedure/funtion/module boundaries with a
>'goto', when I use it for time critical code.

Is there any language in ordinary use that permits
a goto to cross a procedure boundary?  If so, how
are goto target name scopes defined?  If not, why
make so much of trying to avoid such goto's? <g>

--Larry Brasfield
Above opinions may be mine alone.
(Humans may reply at unundered larry_br@sea_net.com )

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

[Jeffrey C. Dege]

On Fri, 21 Aug 1998 01:29:16 GMT, Larry Brasfield <larry_br@sea_net.com> wrote:
>
>Is there any language in ordinary use that permits
>a goto to cross a procedure boundary?  If so, how
>are goto target name scopes defined?  If not, why
>make so much of trying to avoid such goto's? <g>

C's setjmp()/longjmp() functions provide for a goto() across procedure
boundaries.  Or at least from a function to a function that called it.

-- 
"It is not Microsoft's monopoly that I object to, it is the mediocrity of
their products." -- Larry Ellison, CEO of Oracle

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

[Phlip]

Jeffrey C. Dege wrote in message ...

>On Fri, 21 Aug 1998 01:29:16 GMT, Larry Brasfield
<larry_br@sea_net.com> wrote:
>>
>>Is there any language in ordinary use that permits
>>a goto to cross a procedure boundary?  If so, how
>>are goto target name scopes defined?  If not, why
>>make so much of trying to avoid such goto's? <g>
>
>C's setjmp()/longjmp() functions provide for a goto() across procedure
>boundaries.  Or at least from a function to a function that called it.


We all know that's not what Ell thought he meant, if anything.

>--
>"It is not Microsoft's monopoly that I object to, it is the mediocrity
of
>their products." -- Larry Ellison, CEO of Oracle

  --  Phlip                  (no replies - address munged)
======= http://users.deltanet.com/~tegan/home.html =======
  --  Whip me. Beat me. Make me install Oracle.  --

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

[Larry Brasfield]

Jeffrey C. Dege wrote in message ...
>On Fri, 21 Aug 1998 01:29:16 GMT, Larry Brasfield <larry_br@sea_net.com> wrote:
>>
>>Is there any language in ordinary use that permits
>>a goto to cross a procedure boundary?  If so, how
>>are goto target name scopes defined?  If not, why
>>make so much of trying to avoid such goto's? <g>

(Assembler allows cross-procedure jumps.  Most
variants require goto's for interesting programs.)

>C's setjmp()/longjmp() functions provide for a goto() across procedure
>boundaries.  Or at least from a function to a function that called it.

setjmp/longjmp provide stack adjustment as well.
This makes longjmp closer to a form of return, IMO.
Perhaps "computed return" since its argument
determines which setjmp call to return (again) from.

Where I have seen setjmp/longjmp used effectively,
it made the code easier to understand in much the
same way that exceptions in other languages can.
This resembles the conservative use of goto when
it is constrained to a well defined path taken only
for exceptional conditions.

--Larry Brasfield
Above opinions may be mine alone.
(Humans may reply at unundered larry_br@sea_net.com )

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

[dewar]

<<> Good point. Typically in this case I would "cheat" it and embed the inside
of
> the loop in a subprogram, with a return statement. . . . >>

This is typical of the kind of obfuscation that I find odd when it is used
in a desparate attempt to avoid a goto spelled G-O-T-O.

A return *is* a goto statement, so is an exit statement. They are both
reasonably well disciplined goto statements, so this means they are neither
better nor worse than corresponding disciplined use of goto.

But to introduce a procedure just for the purpose of avoiding spelling the
goto with g-o-t-o seems very strange.

It is like an alcoholic thinking it is OK to put fruit and yeast in a pot
and drink it months later, because, after all, no alcohol was put in the
pot :-)


-----== 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)

[Martin Dowie]

In article <6rnh8p$dno$1@nnrp1.dejanews.com>, dewar@gnat.com writes
>This is typical of the kind of obfuscation that I find odd when it is used
>in a desparate attempt to avoid a goto spelled G-O-T-O.
>
>A return *is* a goto statement, so is an exit statement. They are both
>reasonably well disciplined goto statements, so this means they are neither
>better nor worse than corresponding disciplined use of goto.

but the arguement for not using 'goto' is that it is up to the
programmer to get it right, and that they can send the flow of
control anywhere.

it is up to the compiler writer to get the 'return' to go to the
right place and the language defines exactly where that should be.

i'm sure that you're compilers got it right mr dewar ;-)
-- 
Martin Dowie

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

[Martin Dowie]

In article <$3XHNBAxSZ41Ew4G@dowie-cs.demon.co.uk>, Martin Dowie
<martin@dowie-cs.demon.co.uk> writes
>In article <6rnh8p$dno$1@nnrp1.dejanews.com>, dewar@gnat.com writes
>>This is typical of the kind of obfuscation that I find odd when it is used
>>in a desparate attempt to avoid a goto spelled G-O-T-O.
>>
>>A return *is* a goto statement, so is an exit statement. They are both
>>reasonably well disciplined goto statements, so this means they are neither
>>better nor worse than corresponding disciplined use of goto.
>
and all the "Jackson" fans will want to point out that there
is no such thing as a 'goto' of data structures, but there
are sequences, selections and iterations.
-- 
Martin Dowie

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

[Mark A Biggar]

Martin Dowie wrote:
> In article <$3XHNBAxSZ41Ew4G@dowie-cs.demon.co.uk>, Martin Dowie
> <martin@dowie-cs.demon.co.uk> writes
> >In article <6rnh8p$dno$1@nnrp1.dejanews.com>, dewar@gnat.com writes
> >>This is typical of the kind of obfuscation that I find odd when it is used
> >>in a desparate attempt to avoid a goto spelled G-O-T-O.
> >>A return *is* a goto statement, so is an exit statement. They are both
> >>reasonably well disciplined goto statements, so this means they are neither
> >>better nor worse than corresponding disciplined use of goto.
> and all the "Jackson" fans will want to point out that there
> is no such thing as a 'goto' of data structures, but there
> are sequences, selections and iterations.

Yes, there is, Pointers are the data structure equivelant of the goto statement.
Multiple aliases can get you into worse trouble then goto's any day.
At least a goto has an explisitly labeled target, while in most languages
a variable with multiple aliaes has no marking what-so-ever.  Note, that
Ada is one of the few languages that requires such marking with the 
"aliased" keyword.

--
Mark Biggar
mark.a.biggar@lmco.com

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

[Martin Dowie]

In article <35E1E74D.AF98CE26@lmco.com>, Mark A Biggar
<mark.a.biggar@lmco.com> writes
>Yes, there is, Pointers are the data structure equivelant of the goto statement.
>Multiple aliases can get you into worse trouble then goto's any day.
>At least a goto has an explisitly labeled target, while in most languages
>a variable with multiple aliaes has no marking what-so-ever.  Note, that
>Ada is one of the few languages that requires such marking with the 
>"aliased" keyword.

but the data structures that 'jacksonites' refer to are
the 'real world' ones eg. a report might consist of
a title page, plus a contents page, plus an iteration
of text pages plus an iteration of index pages.

also, can't see who you equate a pointer to a goto. eg

type ptr is access ...;

type rec is record
   int:integer;
   my_ptr:ptr;
end record;

here, the point forms part of a sequence. the thing
a pointer points to itself has a specific structure
which can be descibed in terms of sequences, selections
and iterations. i would have thought a better equivilant
of a pointer would be a subprogram.

anyway, suffice to say that 'jacksonites' tend to be the
biggest 'goto-phobes' in any office.
-- 
Martin Dowie

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

[Mark A Biggar]

Martin Dowie wrote:
> In article <35E1E74D.AF98CE26@lmco.com>, Mark A Biggar
> <mark.a.biggar@lmco.com> writes
> >Yes, there is, Pointers are the data structure equivelant of the goto statement.
> >Multiple aliases can get you into worse trouble then goto's any day.
> >At least a goto has an explisitly labeled target, while in most languages
> >a variable with multiple aliaes has no marking what-so-ever.  Note, that
> >Ada is one of the few languages that requires such marking with the
> >"aliased" keyword.
> but the data structures that 'jacksonites' refer to are
> the 'real world' ones eg. a report might consist of
> a title page, plus a contents page, plus an iteration
> of text pages plus an iteration of index pages.

Yes but even that description may contain what are efectively pointers,
what do you think goes in the bibliography end the end of the document.
And, what is a URL but a pointer.


> also, can't see who you equate a pointer to a goto. eg
> type ptr is access ...;
> type rec is record
>    int:integer;
>    my_ptr:ptr;
> end record;

But, that's a controlled use of pointers, just like "return" and "exit" are
controlled uses of "goto".  It's cases like the following where pointers
are like uncontrolled goto's:

type ptr is access all integer;

X: aliased integer;

Y: ptr := X'ACCESS;

or even worse

Y: ptr := X'UNCHECKED_ACCESS;

--
Mark Biggar
mark.a.biggar@lmco.com

> 
> here, the point forms part of a sequence. the thing
> a pointer points to itself has a specific structure
> which can be descibed in terms of sequences, selections
> and iterations. i would have thought a better equivilant
> of a pointer would be a subprogram.
> 
> anyway, suffice to say that 'jacksonites' tend to be the
> biggest 'goto-phobes' in any office.
> --
> Martin Dowie

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

[Martin Dowie]

In article <35E2FC29.954D706C@lmco.com>, Mark A Biggar
<mark.a.biggar@lmco.com> writes
>Martin Dowie wrote:
>> but the data structures that 'jacksonites' refer to are
>> the 'real world' ones eg. a report might consist of
>> a title page, plus a contents page, plus an iteration
>> of text pages plus an iteration of index pages.
>
>Yes but even that description may contain what are efectively pointers,
>what do you think goes in the bibliography end the end of the document.
>And, what is a URL but a pointer.

a data structure for a biblography would be an iterations of
one or more references, a reference in turn would be broken
down, say in to a sequence of author plus title plus ISBN

A URL is an iteration of characters, a broswer program to
use this URL data structure would have an iteration of
URLs as its input.

"pointing" is a function, but the only data structures
allowed for in JSP are sequence, selection and iteration,
as jackson argues that these are the data structures found
in the 'real world', and since or program design is meant
to model this 'real world' he argues there is no place
for a 'goto' in program design - how it's implemented is
a different matter.

-- 
Martin Dowie

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

[adam]

In article <$3XHNBAxSZ41Ew4G@dowie-cs.demon.co.uk>,
  Martin Dowie <martin@dowie-cs.demon.co.uk> wrote:

> but the arguement for not using 'goto' is that it is up to the
> programmer to get it right, and that they can send the flow of
> control anywhere.
>
> it is up to the compiler writer to get the 'return' to go to the
> right place and the language defines exactly where that should be.

If this is a good argument against GOTO, it's an even better argument against
using assignment statements, expressions, procedure calls, and any other
language constructs that actually perform any work.

After all, when you use an assignment statement, look at the number of things
that the programmer could get wrong.  They can mistype the variable name on
the left side.	If the right-hand side is an expression, they could get wrong
any of the variables in the right side, or the operators, or the location of
parentheses, etc.  I've made all these mistakes many, many times.

So is using a GOTO any worse?  Is the chance of getting a GOTO wrong
significantly greater than the chance of screwing something else up?  I sure
don't see it.  The most likely error is that the programmer puts the label in
the wrong place.  But remember what the whole "return" thing was about:  one
programmer said that instead of

    for J in 1 .. N loop
       if condition 1 then
          ...
          if condition 2 then
             ...
             if condition 3 then
                goto Continue;

he would extract the code into a subroutine and use "return" instead of "goto
Continue".  Well, if the programmer got the location of the label CONTINUE
wrong, whether via a logic error or a typo, why is it any less likely that
the programmer would get the "continue" location wrong when
cutting-and-pasting the code he/she wants to extract into a subroutine?

The arguments against GOTO seem to keep getting lamer and more disconnected
from real programming experience.

				-- Adam





-----== 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)

[dennison]

In article <6rnh8p$dno$1@nnrp1.dejanews.com>,
  dewar@gnat.com wrote:
> <<> Good point. Typically in this case I would "cheat" it and embed the inside
> of
> > the loop in a subprogram, with a return statement. . . . >>
>
...
> A return *is* a goto statement, so is an exit statement. They are both
> reasonably well disciplined goto statements, so this means they are neither
> better nor worse than corresponding disciplined use of goto.

Perhaps. But two years from now the maintainer will have no clue how
"disciplined" I am being with that goto, without reading every line of code to
make sure.

This whole line of reasoning makes me very uncomfortable, as it has a striking
similarity to the arguments I used to hear against strong-typing. After all, a
disciplined software engineer won't need strong-typing either, right? It will
just get in his way.


> It is like an alcoholic thinking it is OK to put fruit and yeast in a pot
> and drink it months later, because, after all, no alcohol was put in the
> pot :-)
Geez. I see your point. I guess I do tend to horribly abuse exit and return.
Perhaps I need to start going to the meetings again. :-)

--
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)

[Matthew Heaney]

dennison@telepath.com writes:

> This whole line of reasoning makes me very uncomfortable, as it has a
> striking similarity to the arguments I used to hear against
> strong-typing. After all, a disciplined software engineer won't need
> strong-typing either, right? It will just get in his way.

No.  Among other things, the purpose of strong typing is to prevent
accidents, not get in your way.  If a "strongly typed" abstraction is
difficult to use, then something is wrong with the implementation of the
abstraction.

Saying that strong typing gets in your way is a little like saying that
using a speedometer gets in your way, because you can't see how fast the
wheel is rotating.

All a language can do is give the programmer the tools he needs to
compose abstractions.  If the programmer writes bad abstractions, by
misusing the type system, then it's the fault of the programmer.

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

[dennison]

In article <m3iujetijb.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:
> dennison@telepath.com writes:
>
> > This whole line of reasoning makes me very uncomfortable, as it has a
> > striking similarity to the arguments I used to hear against
> > strong-typing. After all, a disciplined software engineer won't need
> > strong-typing either, right? It will just get in his way.
>
> No.  Among other things, the purpose of strong typing is to prevent
> accidents, not get in your way.  If a "strongly typed" abstraction is
> difficult to use, then something is wrong with the implementation of the
> abstraction.
>
> Saying that strong typing gets in your way is a little like saying that
> using a speedometer gets in your way, because you can't see how fast the
> wheel is rotating.

My point exactly. Why doesn't this same logic apply to goto's vs. more
structured flow control statements?

--
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)

[Matthew Heaney]

dennison@telepath.com writes:

> > Saying that strong typing gets in your way is a little like saying that
> > using a speedometer gets in your way, because you can't see how fast the
> > wheel is rotating.
> 
> My point exactly. Why doesn't this same logic apply to goto's vs. more
> structured flow control statements?

The premise to your argument is that goto-less ("more structured")
control flow statements are better then using a goto directly.  What we
are debating is whether to accept this premise.

My only criterion for goodness is whether something makes the program
easier to understand.  Is the program more or less complex by using the
statement?  This question can only be answered by the human programmers
that write programs using the statement.

Bohm-Jacopini showed that only 3(?) constructs were necessary to
implement all control flow.  But so what?  They weren't saying don't use
other constructs.

In one of his books, Dijkstra spoke of minimizing the "intellectual
distance" between the problem and its solution (in the form of a
computer program).

If using a goto makes the implementation of an algorithm simpler, then
I'm all for it.  The goal IS "make the program simple to understand."
The goal is NOT "don't use a goto."

When I write a state-based abstraction - for example, just about any
task - then the first thing I do is write a little state transition
diagram.  This is my problem.  Now I want to transform this problem into
a solution. 

To reduce translation error, I want be able to translate the STD more or
less directly into program text.  The _simplest_ way, in my opinion, is
to use a goto.  This allows me to easily navigate among the states,
directly, just like in the STD.

Now this doesn't mean a solution using "more structured" control flow
statements isn't possible.  Of course it's possible.  But what we're
debating is whether this alternate solution is better than the goto.

What is deemed "better" is a social phenonmenon.  God did not decide
that goto-less control flow is better.  You did, by making a personal
choice.  Other programmers (like me and Robert) have made a different
choice.

One can come up with a theory about whether something is better, but any
theory must stand the test of observation.  Any theory which contradicts
observation should be thrown out.

Any theory about using (or not using) a programming construct needs to
be tested against observation, by performing an empirical study that
measures the defect rates of programmers using the construct.

If theory says use a construct, but observation reveals that programmers
who use the construct produce more errors, then the theory needs to be
thrown out.

For example, there's a pernicious myth that exiting (or returning) from
the middle of a loop is bad, and that the only proper way to write a
loop is to state the termination condition explicitly, as a predicate
appearing at the top of the loop.

This theory was indeed put to the test, and guess what?  Programmers
using a test-and-exit from the middle of the loop produced fewer errors
than those programmers who tried to put the test at the top of the loop.
The researchers found that the exit-from-the-middle construct had a
better "cognitive fit" than the other constructs.

If you want to read the gory details, the article is

Cognitive Strategies and Looping Constructs: An Empirical Study
Soloway, Bonar, Ehrlich
CACM, Nov 83, Vol 26, No 11, p 853-860

The goodness of a language construct should not be determined by
doctrinaire computer scientists or mathematicians.  The only thing that
matters is whether working programmers think it's easier to understand,
and whether by using the construct programmers inject fewer errors into
the code.

I think it was Stroustrup who said, "Programming is a human activity.
Forget that, and all is lost."

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

[John G. Volan]

Matthew Heaney wrote:
> 
> For example, there's a pernicious myth that exiting (or returning) from
> the middle of a loop is bad, and that the only proper way to write a
> loop is to state the termination condition explicitly, as a predicate
> appearing at the top of the loop.

Maybe the real problem is not where the loop exit occurs _vertically_,
but rather where it occurs _horizontally_ -- that, at what nesting
depth.  Take a look at the thread "Mid-Loop 'Until' Proposal" from
c.l.e.  Consider the comparison I make between a possible Eiffel
extension that would grant a loop more freedom as to where an "until"
clause could be placed, yet still require the terminating postcondition
to appear at the outermost level of nesting; versus Ada's "exit when"
statement, which can reach out and affect the control-flow of its
enclosing loop from some arbitrarily deep level of nesting.

-- 
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)

[Robert I. Eachus]

In article <6s6h4a$ha9$1@nnrp1.dejanews.com> dennison@telepath.com writes:

 > My point exactly. Why doesn't this same logic apply to goto's vs. more
 > structured flow control statements?

   Let's not start this argument again. ;-)  But there is visible bias
in your question, which has to be rooted out before the answer is
obvious.  There are many situations in which if statements, for loops,
while loops, etc., are more structured than gotos.  So if you want to
write a well structured program you use them.  There are a few cases
where the best structure uses gotos.  In those cases, if you are
trying to write a well structured program, you use a goto--unless you
are molested by the goto gestapo.  In my personnal experience, these
have only occured in programs which implemented finite state machines.
(And even then the main FSM loop was implemented as a loop.  The gotos
were to deal with special cases such as the final state.)

    There are rather more cases where the goto is better than the
stuctures available in langauges not as rich as Ada.  In those cases
the best choice may be to change languages. ;-)
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

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

[Charles H. Sampson]

<dewar@gnat.com> wrote:
> ...
> 
> A return *is* a goto statement, so is an exit statement. They are both
> reasonably well disciplined goto statements, so this means they are neither
> better nor worse than corresponding disciplined use of goto.
> 
> ...

     O. k., I'll bite.  In what sense are return statements and exit state-
ments goto statements?  The only commonalty I can see is that all three are
in the class that used to be called "transfer of control" statements.  Be-
fore I comment further, I want to make sure I fully understand the claim.  
(Similar statements have been made by several people.  I'm just picking on 
the guy that I consider best able to defend himself.)

     I got in very late on this thread, which is why I haven't participated
before.  I've found it very interesting, but it does tend to go on.  I have
a 31-day backlog of c.l.a posts and it's amazing how many of them are de-
voted to this one thread.

                                        Charlie

-- 
     To get my correct email address, replace the "claveman" by
"csampson" in my fake (anti-spam) address.

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

[Ell]

"Larry Brasfield" <larry_br@sea_net.com> wrote:

>Ell wrote in message <35dfb9a8.4685477@news.erols.com>...
>>
>>ell@access.digex.net (Ell) wrote:
>>>
>>>I'm willing to use 'goto' in time critical code where inlines are not
>>>possible, to save stack winding and unwinding.  Other than that I'd
>>>rather use a procedure call and returns to get back.

>>And even then, I try to organize the code so that I invoke 'goto
>>:labelX' and jump to its target ':labelX' **within** a single
>>procedure/function/module.

>>I try **never** to cross procedure/funtion/module boundaries with a
>>'goto', when I use it for time critical code.

>Is there any language in ordinary use that permits
>a goto to cross a procedure boundary?  If so, how
>are goto target name scopes defined?

I'm so into the aphorism that I've never even tried to cross function,
or procedure boundaries in C, C++, or Pascal using 'goto :labelX'.

>If not, why
>make so much of trying to avoid such goto's? <g>

Even within a function or procedure, things can get hairy.  I think
that in general within a function, or procedure, flow control should
only be diverted by conditionals like 'if', 'case', or 'while/do'.
And in general the most extreme flow control action by these
conditionals should be 'return', or a procedure/function call.

Elliott
-- 
   :=***=:  Objective  *  Pre-code Modelling  *  Holistic  :=***=:
                 Hallmarks of the best SW Engineering
         "The domain object model is the foundation of OOD."
 Check out SW Modeller vs SW Craftite Central : www.access.digex.net/~ell
   Copyright 1998 Elliott. exclusive of others' writing. may be copied
     without permission only in the comp.* usenet and bitnet groups.

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

[Bob Collins]

In article <M34D1.9023$hr3.4288091@news.rdc1.bc.wave.home.com>, "Larry
Brasfield" <larry_br@sea_net.com> wrote:

> Is there any language in ordinary use that permits
> a goto to cross a procedure boundary?  If so, how
> are goto target name scopes defined?  If not, why
> make so much of trying to avoid such goto's? <g>

IIRC, Pascal (the CDC Pascal I used in the 70s and
80s), allowed gotos to any label in scope. In the
main program, one could declare a label (mine was an
emergency 666:) and then goto that label from any
procedure or function inside the main program. I
used that for emergency exits, when I ran out of
storage or some such thing. Ada exceptions eliminated
that goto need.

I don't know about modern Pascal.

-- 
Bob Collins  <mailto:collins@cs.wm.edu>  <http://ratbert.cs.wm.edu>

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

[Charles Hixson]

That is the same as the argument for break and continue.  A good one I
feel.  It is true that, as was written earlier, break and continue are
always(?) implemented as-if they were goto statements, nevertheless
because of their restricted compass (either the immediate block, or a
named enclosing block) they do not impair code readability to the same
extent as the goto does.  As a famous man once said "GoTo considered
harmful to programming".
It has been years since I used a language so crippled that I choose an
algorithm construction that required a goto to properly implement it. 
Please note that that is a two-part statement, partially language design
and partially algorithm choice.  Ada is not such a crippled language, as
"exit when" is a perfectly adequate loop-leaving method.  (I'm not sure
what Ada has that corresponds to continue, but that is a less frequently
needed choice).

ell@access.digex.net wrote:
> 
> In article <6r9f8h$jtm$1@nnrp1.dejanews.com>,
>   dennison@telepath.com wrote:
> > In article <dewar.903281994@merv>,
> >   dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
> > > T.E.D says
> > >
> > > But it's a toss up in this case, and for most purposes we would prefer
> > > the second case. Where it gets tricky is
> > >
> > >    for J in 1 .. N loop
> > >       if condition 1 then
> > >          ...
> > >          if condition 2 then
> > >             ...
> > >             if conditoin 3 then
> > >                goto Continue;
> > >
> > > Now T.E.D's prescription is not so clear, and we end up having to
> > > severely contort things, or introduce a boolean flag which we keep
> > > testing as we unwind to the end.
> > >
> > > Remember that the continue here is just like a return. If you are allergic
> > > to using a loop continue or exit, you should be allergic to using a return
> > > (other than at the end of a function). Some people are, and that is at
> > > least consistent. But I see a lot of Ada programmers who will use a return
> > > without hesitation from a nested loop, but still turn green at the sight
> > > of a goto. That makes no sense to me.
> 
> 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'.
> 
> Elliott
> 
> -----== Posted via Deja News, The Leader in Internet Discussion ==-----
> http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

-- 
Charles Hixson	charleshixson@earthling.net
(510) 464-7733	or chixso@mtc.dst.ca.us

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

[Gerry Quinn]

In article <6renh8$ga7$1@nnrp1.dejanews.com>, ell@access.digex.net wrote:

>
>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'.
>

I never realised that!  Who are these fiends who rechannel my gotos?

- Gerry

----------------------------------------------------------
  gerryq@indigo.ie  (Gerry Quinn)
----------------------------------------------------------

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

[Jay Martin]

dennison@telepath.com wrote:
> 
> In article <dewar.903074236@merv>,
>   dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
> > Andy said
> >
> > <<Ahh... but have you ever found a "good" reason for using it? I have used
> > goto in C and Pascal in certain rare cases, but I have always found clearer
> > ways to code these cases in Ada.
> > >>
> >
> > The two obvious uses vfor gotos in Ada are
> >
> > 1) to get a loop "continue" mechanism
> 
> for a simple loop, embedding the rest of the loop code in the body of the if
> statement is clearer. For nested loops where you want to "continue" an outer
> loop, I can see it. Not that I'd do such a thing. As a "goto-holic" who has
> been straight for 10 years, the best bet is abstinence. One day at a time. :-)
> 
> > For example, I find the following perfectly clear:
> >
> >    <<sort>> for J in 1 .. N - 1 loop
> >        if D (J) > D (J + 1) then
> >         Swap (D(J), D(J + 1));
> >           goto Sort;
> >        end if;
> >
> > It is a little tricky to program this without the goto and not make it
> > less clear. Actuallky many people who try this end up with a different
> > algorithm (hint: the above sort is cubic, it is NOT a quadratic bubble sort
> :-)
> 
> So the "average" poor maintainer schlep looks at this and thinks "is this
> just a continue, or a complete restarting of the loop?" Oh yeah, that's
> clear. %-(
> 
> If anyone does something this bizzare, they'd better put copious comments
> around it explaining its semantics. Otherwise, its the software equivalent of
> a land mine. Its just sitting there waiting for someone to touch it, then
> ...BOOM!
> 
> Very good counterexample to your own point.

Yup.

I'll take my stab at what I think the algorithm is doing.
I prefer flags and subroutines to gotos.

inline
void SwapFirstOutOfOrderElements(T D[], int N, bool& NoOutOfOrderElements) 
{
   NoOutOfOrderElements = true;
   for(int J = 0; J < (N-1); J++) {
      if (D[J] > D[J+1]) {
         Swap(D[J], D[J+1]);
         NoOutOfOrderElements = false;
         break;
      }//if//
   }//for//
}//SwapFirstOutOfOrderElements//

      
inline 
void SomeoneShootMeSort(T D[], int N) {    
   bool NoOutOfOrderElements;
   do {
      SwapFirstOutOfOrderElements(D, N, NoOutOfOrderElements);
   } while (!NoOutOfOrderElements);
}


Heh, its probably got a bug some where in there and
heh, do-while syntax sure sucks.  The subroutine name
is probably too short, maybe it should be
"ScanFromTheFrontOfTheArrayAndSwapTheFirstTwoAdjacentOutOfOrderElements".
No wait thats too short....


Maybe we should now go onto exponential time and random "highly
probable to be sorted" sorts.

Jay

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

[Robert Dewar]

May I suggest that if anyone else wants to post alternative solutions to
my sorting statement, that they run them to at least make sure that they do
in fact have the effect of sorting the data?

If your algorithm does not sort, it is most certainly not equiavlent to
what I wrote. Of course if it does sort, it still does not mean it is
the same algorithm :-)