Is there an ADA analogue to the C++ continue statement?

Is there an ADA analogue to the C++ continue statement?

[Heath, Terry D.]

Almost all of my programming is done in C++, and I have never
programmed in Ada (my loss!), although I have seen some examples of
Ada syntax.

I am curious, does Ada have a statement analogous to the C++ continue
statement (see immediately below) ?

EXAMPLE OF C++ CONTINUE STATEMENT:

         while (condition-1)
               {
                     statement-1;

                     if (condition-2)
                         continue;

                     statement-3;
                }

In the above, if condition-2 evaluates to be true, then flow of
control is immediately transferred back to the top of the while loop
(where condition-1 is then tested for, in order to determine whether
iteration of the while loop is to continue).

Note, although the word 'continue' might suggest a NOP type
instruction (NOP = No OPeration ... just continue forward!), that is
not what occurs in C++ (instead, a jump occurs as described in the
previous sentence)  ...  they should have chosen a better name for
the statement !

That is, the C++ continue statement has the opposite effect to the
Ada exit statement (the former transfers flow of control to the start
of the loop construct, whereas the latter transfers control to the
end of the loop construct).

Certainly, the pattern of execution defined by the pseudo-code above
can be implemented by way of traditional structured programming
techniques without recourse to a 'continue' type statement such as
that above.  Nonetheless, I believe the flow of control defined by
the pseudo-code above to be consistent with all widely accepted
structured programming principles (after all, it is just the reverse
concept of that underpinning the Ada exit statement).

So, does Ada have a statement analogous to the C++ continue statement
?

Thanks in advance,
Terry. 

Re: Is there an ADA analogue to the C++ continue statement?

[Robert Dewar]

Terry says

<<Note, although the word 'continue' might suggest a NOP type
instruction (NOP = No OPeration ... just continue forward!), that is
not what occurs in C++ (instead, a jump occurs as described in the
previous sentence)  ...  they should have chosen a better name for
the statement !>>


I guess we don't teach the old stuff any more :-)

Continue has ancient roots in loopology from Fortran days :-)

Re: Is there an ADA analogue to the C++ continue statement?

[Pascal Obry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1279 bytes --]


Heath, Terry D. ask about an Ada equivalent for :

>         while (condition-1)
>               {
>                     statement-1;
>
>                     if (condition-2)
>                         continue;
>
>                     statement-3;
>                }

What come in mind is :

while condition-1 loop
    statement-1;
    if not condition-2 then
        statement-3;
    end if;
end loop;

Note that the C/C++ break statement and the exit statement is Ada
are equivalent.

Pascal.
--

--|------------------------------------------------------------
--| Pascal Obry                               Team-Ada Member |
--|                                                           |
--| EDF-DER-IPN-SID- Ing�nierie des Syst�mes d'Informations   |
--|                                                           |
--| Bureau G1-010           e-mail: pascal.obry@der.edfgdf.fr |
--| 1 Av G�n�ral de Gaulle  voice : +33-1-47.65.50.91         |
--| 92141 Clamart CEDEX     fax   : +33-1-47.65.50.07         |
--| FRANCE                                                    |
--|------------------------------------------------------------
--|
--|   http://ourworld.compuserve.com/homepages/pascal_obry
--|
--|   "The best way to travel is by means of imagination"

Re: Is there an ADA analogue to the C++ continue statement?

[Robert A Duff]

In article <5vqm61$fu2$1@cf01.edf.fr>,
Pascal Obry <pascal.obry@der.edfgdf.fr> wrote:
>Note that the C/C++ break statement and the exit statement is Ada
>are equivalent.

Except that C break statements are broken with respect to switch
statements!

- Bob

Re: Is there an ADA analogue to the C++ continue statement?

[Samuel Tardieu]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 439 bytes --]


>>>>> "Pascal" == Pascal Obry <pascal.obry@der.edfgdf.fr> writes:

Pascal> Note that the C/C++ break statement and the exit statement is
Pascal> Ada are equivalent.

Not quite, since the Ada �exit� statement allows you to go out of more 
than one loop at a time, while in C you end up using multiple �exit�
with boolean (read integer, this is C! :-) variables to make them
cascaded.

  Sam
-- 
Samuel Tardieu -- sam@ada.eu.org

Re: Is there an ADA analogue to the C++ continue statement?

[Robert Dewar]

Heath, Terry D. ask about an Ada equivalent for :

>         while (condition-1)
>               {
>                     statement-1;
>
>                     if (condition-2)
>                         continue;
>
>                     statement-3;
>                }


The most reasonable translation is to introduce a very stylized use of
the goto for this purpose, putting a label <<CONTINUE>> just before the
end loop, and then doing a goto to get the effect you want. So we would
have:

    while Condition_1 loop
       statement_1;

       if Condition_2 then
          goto Continue;
       end if;

       statement_3;
  
    <<Continue>>
    end loop;

Now for some odd reason, many programmers have picked up allergies to gotos
that are spelled using the goto keyword, though these same programmers do
not mind gotos spelled with other keywords such as continue (the continue,
since it can rip you out of deeply nested structures, is of course a form
of goto, it just doesn't look like a goto, but it quacks like one :-)

Yes, yes, we all understand that general inappropriate use of gotos is
a BAD THING. For me that is just a special rule that general inappropriate
use of *any* feature in a language is a bad thing. I don't stop myself using
case statements in my programs just because some idiots misuse them, and
equally I have no problem using goto in a stylized way as shown above just
becausee some idiots misuse them.

Whether the continue is sufficiently important to include as a fundamental
gizmo is a continuing (ha ha) discussion in language design. Algol-60 did
not have this construct, and the algol family generally followed this
lead. Pascal for instance has no goto, and the one place you will find
goto used in Wirth's book on algorithms is precisely for the continue
construct given above (actually that's not quite true, there is another
place where he uses it for a break out on an exceptional condition, but
one would be more likely to use an exception for this purpose in Ada.

Yes, it is possible to use a Boolean flag instead, but the fiddling around
to do this can be a bit tortured if we contrive a deeply nested case.

Final note: for Ada programmers who are incurably goto-challenged, you can
achieve exactly the same effect as the above loop by using:

   while Condition_1 loop
   begin
  //// ooops let's try that again

   while Condition_1 loop
   declare
      Continue : exception;
   begin
      statement_1;

      if Condition_2 then
         raise Continue;
      end if;

      statement_3;

   exception
      when Continue => null;
   end loop;

A kind compiler will translate this use of exceptions into a simple goto
and bypass the normal exception mechanism. Why anyone would go to such
circumlocutions escapes me, but some programmers will do almost anything
to avoid the goto keyword, and besides there are silly coding standards
around which totally forbid the use of the goto keyword.

Why silly? Well to me, most absolute rules are a mistake, since there are
almost always exceptions. Note that I avoid the mistake of phrasing this
particular rule in absolute terms :-)

Robert

Re: Is there an ADA analogue to the C++ continue statement?

[dan13]

William Dale Jr wrote:
[SNIP]
> 
> > Why silly? Well to me, most absolute rules are a mistake, since there are
> > almost always exceptions. Note that I avoid the mistake of phrasing this
> > particular rule in absolute terms :-)
> >
> > Robert
> 
> OK, but if you work on my project  -- NO GOTO's.

 I'll bet you also think that there's a magic number which
represents the maximum allowable lines-of-code in a procedure.

 Any coding standard, or project commandment, or mindset, which
bars usage of GOTO *unconditionally* ... is ABSOLUTELY silly.
Yes, GOTO is to be avoided (as a goal), no sane person argues
this. Yet there are times when using a GOTO enhances the
readability - and thus the maintainability - of the code.

 Coding standards etc... should be thought of as *guidelines*;
with "violations" of the guidelines being vetted by some project
specific process.

> 
> [I'd suspect a troll for flames was going on here but I have great
>  respect for Roberts' previous posts ]
>

 Didn't sound at all like a troll here :)
 


                                             imho

                                                 dan13

Re: Is there an ADA analogue to the C++ continue statement?

[Robert Dewar]

William Dale said

<<> [I'd suspect a troll for flames was going on here but I have great
>  respect for Roberts' previous posts ]>>


Suggesting that goto has useful applications in some cases should NOT
be a troll, since there should be no sensible reason for people to
take offence at the suggestion, but in a typical display of
huper-correctism, it is quite true that a lot of people in the
programming area have distorted the very reasonable rules about not
misusing gotos into the entirely silly rule of abolishing them 
completely.

I suppose if your programmers are so incompetent that they cannot tell
the difference, then such arbitrary rules may help, but in the long run,
there is no magic cure for incompetence to be found in little books of
mindless rules.

One of the nice things about AQ&S is that it clearly understands its role
as a source of guidelines, rather than absolute rules. 

I have no objection to absolute style rules where we are taling about
stylistic issues which have no impact on expressive power (e.g. whether
to indent 3 or 4 characters). Here absolute rules to ensure conformity
are quite appropriate.

But all rules that ban a particular language feature across the board
are misguided (and I really do intend this as an absolute statement).
A feature is in the language because the designers thought it was useful,
and an international standards group unanimously agreed with the design.
If you think a feature is so dangerous that it should never ever be used,
then most probably there is something that you don't understand.

Re: Coding Standards & GOTO

[Matthew Heaney]

In article <3426B51E.7296@lmco.com>, William.Dale.Jr@lmco.com wrote:


>As my charter for implementing a new Ada 95 standard is to have only 
>absolute rules that cannot be violated, 

You are setting yourself up for failure, as there is no such thing as an
absolute rule.

>I am forced to through out most 
>of AQ&S as mearly advice.  

Why the pejorative "merely advice"?  That's exactly what a coding standard
should be, advice on how to use language.

Read the section of OOSC-2 that discusses the difference between a rule and
a guideline.

>A major segment wants to use GOTO's ( visible
>objects in specs too ). I'd use the AQ&S right out of the box if I
>could. 

A "rule" comprises "guidelines," plus a list of the times when the
guidelines don't apply, ie

rule = guidelines + exceptions

For example, state your rule for the use of goto as follows:

Rule For The Use Of The Goto Statement

Guideline:
o Use higher-level control structures such as if, case, and loops, rather
than a goto.

Exceptions:
o Use a goto when you're mechanically translating code from another
language into Ada (example, converting from Fortran to Ada, or when you're
using a scanner generator that emits Ada code).

o Use a goto when you're hand-coding a finite state machine, such as a scanner.

End of Rule


And what's wrong with objects in the spec?  Have you read Ada.Text_IO
lately?  Again, this calls for guidelines for when to declare an object in
the spec, and when not to.  For example, when implementing a subsystem,
then an object shared among packages in the same subsystem can be declared
in the spec of a private package.

Also, a well-known object, used throughout the system, can be declared in a
spec:

package Targets.Objects is

   type Target_Array is array (Positive range 1 .. 20) of Target;

   The_Targets : Target_Array;

end;

What's wrong with that?


>Advice will be ignored, I'm sure, as all programmers know what's best
>for their code.  ;-) 

Not all programmers do know, and they appreciate the help.  Check out
Taligent's Guide to Designing Programs.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Coding Standards & GOTO

[Mark A Biggar]

In article <mheaney-ya023680002209971952370001@news.ni.net> mheaney@ni.net (Matthew Heaney) writes:
>In article <3426B51E.7296@lmco.com>, William.Dale.Jr@lmco.com wrote:
>>As my charter for implementing a new Ada 95 standard is to have only 
>>absolute rules that cannot be violated, 
>You are setting yourself up for failure, as there is no such thing as an
>absolute rule.
>>I am forced to through out most 
>>of AQ&S as mearly advice.  
>Why the pejorative "merely advice"?  That's exactly what a coding standard
>should be, advice on how to use language.
>>A major segment wants to use GOTO's ( visible
>>objects in specs too ). I'd use the AQ&S right out of the box if I
>>could. 
>A "rule" comprises "guidelines," plus a list of the times when the
>guidelines don't apply, ie
>rule = guidelines + exceptions
>For example, state your rule for the use of goto as follows:

It is also usefull to have a meta-exception at the start of your Style Guide
that says something like:

Almost any of the guidelines in this stype guide can be violated in specific
cases, if you can get your inspection/walkthrough team to buy off on it.

You do have inspections don't you?

Also, the best way to enforce any code formatting style guidelines is to 
provide a standard pretty-printer that must be run before the inspection.

--
Mark Biggar
mab@wdl.lmco.com

Re: Coding Standards & GOTO

[W. Wesley Groleau x4923]

> Also, the best way to enforce any code formatting style guidelines is 
> to provide a standard pretty-printer that must be run before the 
> inspection.

If you can find one.  Most of them would more accurately be called
"ugly-printer."

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
----------------------------------------------------------------------

Re: Coding Standards & GOTO

[Shmuel (Seymour J.) Metz]

Mark A Biggar wrote:
> 
> Also, the best way to enforce any code formatting style guidelines is to
> provide a standard pretty-printer that must be run before the inspection.

Those tend to mess up the layout of comments. A better way is to use a 
syntax-oriented editor that lays the code out with proper indentation as
it
is keyed in.

> --
> Mark Biggar
> mab@wdl.lmco.com

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org

Re: Coding Standards & GOTO

[Aaron Quantz]

And don't forget, the most important place to accept deviations to
your CONCRETE rules is during your format code walkthrough. The
deviation can be explained and accepted/rejected on a case-by-case
basis.

mheaney@ni.net (Matthew Heaney) wrote:

>In article <3426B51E.7296@lmco.com>, William.Dale.Jr@lmco.com wrote:
>
>
>>As my charter for implementing a new Ada 95 standard is to have only 
>>absolute rules that cannot be violated, 
>
>You are setting yourself up for failure, as there is no such thing as an
>absolute rule.
>
>>I am forced to through out most 
>>of AQ&S as mearly advice.  
>
>Why the pejorative "merely advice"?  That's exactly what a coding standard
>should be, advice on how to use language.
>
>Read the section of OOSC-2 that discusses the difference between a rule and
>a guideline.
>
>>A major segment wants to use GOTO's ( visible
>>objects in specs too ). I'd use the AQ&S right out of the box if I
>>could. 
>
>A "rule" comprises "guidelines," plus a list of the times when the
>guidelines don't apply, ie
>
>rule = guidelines + exceptions
>
>For example, state your rule for the use of goto as follows:
>
>Rule For The Use Of The Goto Statement
>
>Guideline:
>o Use higher-level control structures such as if, case, and loops, rather
>than a goto.
>
>Exceptions:
>o Use a goto when you're mechanically translating code from another
>language into Ada (example, converting from Fortran to Ada, or when you're
>using a scanner generator that emits Ada code).
>
>o Use a goto when you're hand-coding a finite state machine, such as a scanner.
>
>End of Rule
>
>
>And what's wrong with objects in the spec?  Have you read Ada.Text_IO
>lately?  Again, this calls for guidelines for when to declare an object in
>the spec, and when not to.  For example, when implementing a subsystem,
>then an object shared among packages in the same subsystem can be declared
>in the spec of a private package.
>
>Also, a well-known object, used throughout the system, can be declared in a
>spec:
>
>package Targets.Objects is
>
>   type Target_Array is array (Positive range 1 .. 20) of Target;
>
>   The_Targets : Target_Array;
>
>end;
>
>What's wrong with that?
>
>
>>Advice will be ignored, I'm sure, as all programmers know what's best
>>for their code.  ;-) 
>
>Not all programmers do know, and they appreciate the help.  Check out
>Taligent's Guide to Designing Programs.
>
>--------------------------------------------------------------------
>Matthew Heaney
>Software Development Consultant
><mailto:matthew_heaney@acm.org>
>(818) 985-1271


Regards,
Aaron Quantz                    \^ ^/
                                )@ @(
+---------------------------oOO--(_)------------------------------------+
+ Mgr Software Development, Turret Control Systems                      +
+ HR Textron                        | Phone: (805) 253-5471             +
+ 25200 W. Rye Canyon Rd.           | Fax:   (805) 253-5962             +
+ Valencia, CA USA 91355-1265       | Email: aquantz@ibm.net            +
+ Visit the Textron web site: http://www.textron.com                    +
+-----------------------------------Oooo--oOO---------------------------+
                              oooO (   )
                             (   )  ) /
                              \ (  (_/
                               \_)

Re: Coding Standards & GOTO

[Charles H. Sampson]

In article <mheaney-ya023680002209971952370001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote (among other things):
>
>And what's wrong with objects in the spec?  Have you read Ada.Text_IO
>lately?  Again, this calls for guidelines for when to declare an object in
>the spec, and when not to.  For example, when implementing a subsystem,
>then an object shared among packages in the same subsystem can be declared
>in the spec of a private package.
>
>Also, a well-known object, used throughout the system, can be declared in a
>spec:
>
>package Targets.Objects is
>
>   type Target_Array is array (Positive range 1 .. 20) of Target;
>
>   The_Targets : Target_Array;
>
>end;
>
>What's wrong with that?

     While I agree your basic premise that absolute rules are never 
correct (including this one), what's wrong with this example is that it 
locks anybody who uses this package into the design decision that tar-
gets will be stored in an array.  Change that to a linked list and
you've got a major code modification job.

     This is exactly what Parnas taught us not to do in 1972.  While I 
share your aversion to absolute rules, I almost never have objects in
the visible part of package specs.  The exceptions seem to almost al-
ways be Boolean.

				Charlie
--
******

    If my user name appears as "csampson", remove the 'c' to get my
correct e-mail address.

Re: Coding Standards & GOTO

[Charles Rose]

William Dale Jr wrote:
> As my charter for implementing a new Ada 95 standard is to have only
> absolute rules that cannot be violated, I am forced to through out most
> of AQ&S as mearly advice.  A major segment wants to use GOTO's ( visible
> objects in specs too ). I'd use the AQ&S right out of the box if I
> could.
> 
> Advice will be ignored, I'm sure, as all programmers know what's best
> for their code.  ;-)

We have a coding standard that only contains absolute rules (and
prohibits GOTOs).  But the coding standard also says that deviations are
permitted provided the file header identifies each deviation and
provides a justification.  No approvals are needed.

Re: Coding Standards & GOTO

[Matthew Heaney]

In article <3427E983.6CAC@hazeltine.com>, rose@hazeltine.com wrote:

>We have a coding standard that only contains absolute rules (and
>prohibits GOTOs).  But the coding standard also says that deviations are
>permitted provided the file header identifies each deviation and
>provides a justification.  No approvals are needed.

My advice to writers of coding standards to NOT follow the above advice. 
We tried this on a recent project and guess what: no one even reads the
header.  

Don't publish absolute rules, publish guidelines, and enumerate the times
when the guideline doesn't apply.  

If you the programmer are unsure whether an approach is controversial (say,
using goto's to write a scanner), then get some advice from the good
programmers on your staff.  Advice from a peer whom you respect carries a
lot more weight than absolute rules handed down from Moses.

See Scott Meyers' Effective C++ books, and the Taligent Guide too, for
excellent examples of what a coding standard look like.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Coding Standards & GOTO

[Shmuel (Seymour J.) Metz]

Matthew Heaney wrote:
> 
> My advice to writers of coding standards to NOT follow the above advice.
> We tried this on a recent project and guess what: no one even reads the
> header.

Does that mean that you don't do code reviews, or just that the
reviewers
don't read the headers. IMHO either is bad.
 
> If you the programmer are unsure whether an approach is controversial (say,
> using goto's to write a scanner), then get some advice from the good
> programmers on your staff.  Advice from a peer whom you respect carries a
> lot more weight than absolute rules handed down from Moses.

The programmer should be concerned with whether it's dangerous, not with
whether it's controversial. It's his responsibility to write code that
is
maintainable and robust. If something looks dangerous to him in his
specific 
circumstances, that should be a red flag even if the technique is not 
controversial and has been blessed by the guidelines.

> --------------------------------------------------------------------
> Matthew Heaney
> Software Development Consultant
> <mailto:matthew_heaney@acm.org>
> (818) 985-1271

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org

Re: Coding Standards

[W. Wesley Groleau x4923]

Here we have what at first glance might appear to be a mixture of
"absolute rules" and "merely advice" but in reality the difference
is how hard it is to get a deviation approved.  Even in cases where
no one ever disapproves, the "merely advice" may be valuable for
educating the inexperienced.

The task that is apparently facing William Dale can best be solved
with a single absolute rule:  Code that will not compile is not
acceptable.

Re: Is there an ADA analogue to the C++ continue statement?

[Richard D Riehle]

We should probably change the name of the topic to:

        "Go To Considered Harmful"

reflecting the origins of this notion in the 1968 letter by
E. Dijkstra to the Communications of the ACM.   

No experienced software practitioner, using any language, would
design software so it required a "goto."  During the design phase
of a project we all try to abide by accepted practices that have
proven effective in building reliable software.  However, during 
the implementation phase, when we are actually trying to lay down
clear, maintainable, and efficient code, we sometimes find it 
appropriate to make use of some construct that might horrify the
standards people.  

I can recall only one project where it was appropriate to use a 
"goto" and we required the programmer to justify its use in a meeting 
of his fellow team members, most of whom were congenitally hostile 
to even the thought of a "goto."  He did justify its use, and we agreed 
to let it go (to).

Unfortunately, the people who make up rules for programming are
all too often people who no longer write programs.  Sometimes they
are even people who never have written programs.  I am a firm believer
in coding standards.  I would like to think I also believe in 
common sense.  Sometimes inviolate rules are more the cause of 
problems than the solution.  

Someone one once said that "The last act of a dying organization
was to enlarge the rule book."   Perhaps we should consider carefully
before we legislate ourselves into untenable circumstances.

Richard Riehle
AdaWorks Software Engineering

Re: GOTO considered Satanic (was: Is there an ADA analogue to the C++ continue statement?)

[Adam Beneschan]

In article <3423AF1B.5152@i.b.m.net> dan13@i.b.m.net writes:

 > Any coding standard, or project commandment, or mindset, which
 >bars usage of GOTO *unconditionally* ... is ABSOLUTELY silly.
 >Yes, GOTO is to be avoided (as a goal), no sane person argues
 >this. Yet there are times when using a GOTO enhances the
 >readability - and thus the maintainability - of the code.
 >
 > Coding standards etc... should be thought of as *guidelines*;
 >with "violations" of the guidelines being vetted by some project
 >specific process.

You know, I wonder whether the whole debate over the GOTO has failed
to keep pace with the times.  Back in the 70's, when I started to work
as a programmer and when Dijkstra's paper was still a hot topic, many
of the seasoned programmers around were used to assembly-language
programming, and the other main languages of the time, COBOL and
FORTRAN, didn't have adequate looping and control structures as
today's languages do (including later versions of COBOL).  So it was
common to use GOTO liberally.  At least that's the case where I
worked; many of the older COBOL programs I had to work with truly
deserved the description "spaghetti code".  So those programmers
needed a lot of convincing to make major changes in their style.

Today, I don't think that's the case.  When I helped tutor a beginning
computer science course in 1980 (in Pascal), we didn't even teach the
students about the goto statement.  I don't know what the practice has
been at other institutions, but I'm willing to bet that most
programmers my age (36) or younger have been taught that GOTO is
something to be used rarely, if they haven't been taught that they
will be expelled from college if they write a GOTO.  And the languages
more likely to be used for teaching have much better control
structures than past languages, so that there should be much less
temptation to use GOTO as a crutch.

So I was disappointed to see the style guide say:

     guideline 

  -  Do not use goto statements. 

     rationale 

     A goto statement is an unstructured change in the control flow.
     Worse, the label does not require an indicator of where the
     corresponding goto statement(s) are. This makes code unreadable
     and makes its correct execution suspect.

The absolutist language "This makes code unreadable and makes its
correct execution suspect" hardly seems necessary.  Sure, you can use
GOTO to write unreadable code.  You can use any language feature to
write unreadable code.  But using a GOTO doesn't automatically make
your code unreadable, as this statement seems to imply.  Programmers
in the past often turned their code into linguine, but it seems to me
that this just doesn't happen as often today, due to the anti-GOTO
bias programmers are learning in school; and hopefully when a GOTO is
used, it's much more likely to be done in a readable fashion.

(Plus, I found the style guide's reasoning unconvincing.  They say
GOTO is unreadable because a label doesn't require an indicator of
where the corresponding goto statements are.  But an "exit" statement
is essentially a "goto" to the end of a loop, and loop statements
don't require an indicator of where the "exit" statements are, so how
does this logic show that GOTO's are more unreadable than EXIT?)

Anyway, my point is: This is the 90's.  The battle has been won.  It's
no longer necessary to take the attitude that whenever we see a GOTO,
we should let out a shriek and beat the offending insect to death with
a broom.  We can, and should, adopt a more moderate and less
absolutist tone, one that says that GOTO's are generally unnecessary
and should be avoided but may make code more readable on rare
occasions.

                                -- Adam

Re: GOTO considered Satanic (was: Is there an ADA analogue to the C++ continue statement?)

[Brian Rogoff]

On 23 Sep 1997, Adam Beneschan wrote:
> The absolutist language "This makes code unreadable and makes its
> correct execution suspect" hardly seems necessary.  Sure, you can use
> GOTO to write unreadable code.  You can use any language feature to
> write unreadable code. 

I strongly agree. Whenever I hear the absolute anti-goto rule espoused I 
flippantly remark that named procedures should be disallowed too, since 
bad name choice also hinders readability. "Readability" is not easily 
achieved by slavish adherence to a rulebook. Its achievable with
experienced developers who have good taste. 

In another thread, some rather absolute rules concerning exceptions were 
put forth ("don't use exceptions for normal control flow"). While I think 
thats a good guideline, I've also written code that violates that rule and 
was IMO more readable because of it (if you must know, it was in the top 
level loop for an interpreter for a Lisp like language; I used an exception
to terminate the loop when a (quit) was evaluated). 

-- Brian

Re: GOTO considered Satanic (was: Is there an ADA analogue to the C++ continue statement?)

[Larry Kilgallen]

In article <Pine.SGI.3.95.970924182021.11641A-100000@shellx.best.com>, Brian Rogoff <bpr@shellx.best.com> writes:

> In another thread, some rather absolute rules concerning exceptions were 
> put forth ("don't use exceptions for normal control flow"). While I think 
> thats a good guideline, I've also written code that violates that rule and 
> was IMO more readable because of it (if you must know, it was in the top 
> level loop for an interpreter for a Lisp like language; I used an exception
> to terminate the loop when a (quit) was evaluated). 

I would expect those who implement Ada to take the name "exception" at
face value and feel free to make it considerably less efficient than
other mechanisms.  This is not much of an issue for the (quit)
operation (presuming Lisp has a meaning for that similar to what
I might guess), but for other situations using exceptions in the
normal flow of things would slow them down.

For most programs, readability is not the _only_ goal.

Larry Kilgallen

Re: GOTO considered Satanic (was: Is there an ADA analogue to the C++ continue statement?)

[Matthew Heaney]

In article <Pine.SGI.3.95.970924182021.11641A-100000@shellx.best.com>,
Brian Rogoff <bpr@shellx.best.com> wrote:


>In another thread, some rather absolute rules concerning exceptions were 
>put forth ("don't use exceptions for normal control flow"). While I think 
>thats a good guideline, I've also written code that violates that rule and 
>was IMO more readable because of it (if you must know, it was in the top 
>level loop for an interpreter for a Lisp like language; I used an exception
>to terminate the loop when a (quit) was evaluated). 

Well, there are reasons for not using exceptions for normal control flow:
the famous RM 11.6 (though that section may - I think - only apply to
predefined exceptions; that section still throws me).  If you need a goto,
then use a goto, not an exception.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: GOTO considered Satanic (was: Is there an ADA analogue to the C++ continue statement?)

[Brian Rogoff]

On Fri, 26 Sep 1997, Matthew Heaney wrote:
> In article <Pine.SGI.3.95.970924182021.11641A-100000@shellx.best.com>,
> Brian Rogoff <bpr@shellx.best.com> wrote:
> 
> 
> >In another thread, some rather absolute rules concerning exceptions were 
> >put forth ("don't use exceptions for normal control flow"). While I think 
> >thats a good guideline, I've also written code that violates that rule and 
> >was IMO more readable because of it (if you must know, it was in the top 
> >level loop for an interpreter for a Lisp like language; I used an exception
> >to terminate the loop when a (quit) was evaluated). 
> 
> Well, there are reasons for not using exceptions for normal control flow:
> the famous RM 11.6 (though that section may - I think - only apply to
> predefined exceptions; that section still throws me).  If you need a goto,
> then use a goto, not an exception.

I didn't "need" a goto, a quit call can be deeply nested. The efficiency 
argument is also irrelevant here, as I was quitting. The point is that 
this is an exception :-) to the absolute rule about exceptions. Jon
Anthony's iterator approach in Ada is another. 

As an aside, Matthew, it is unnecessary to send mail *and* follow up the
article. Please learn how to tell your newsreader to just follow up, or 
just send mail.

-- Brian

Re: GOTO considered Satanic (was: Is there an ADA analogue to the C++ continue statement?)

[Robert I. Eachus]

In article <mheaney-ya023680002609970839420001@news.ni.net> mheaney@ni.net (Matthew Heaney) writes:

  > Well, there are reasons for not using exceptions for normal control flow:
  > the famous RM 11.6 (though that section may - I think - only apply to
  > predefined exceptions; that section still throws me).  If you need a goto,
  > then use a goto, not an exception.

  The wording in 11.6(5) in the new RM cleans up this problem almost
completely.  The only case where you can still find yourself fighting
the optimizer is:

   declare
     Junk: Integer;
   begin
     Junk := X * Y;
   exception
     when Constraint_Error => Handle_Value_Too_Big;
   end;

   Since Junk is never referenced, the optimizer is allowed to leave
the value of X * Y undefined, and in fact not compute it.  To do this
type of check correctly try:

   declare
     Junk: Integer;
   begin
     Junk := X * Y;
     if Junk > Integer'LAST 
     then
       Ada.Text_IO.Put_Line("Foo!");
     end if;
   exception
     when Constraint_Error => Handle_Value_Too_Big;
   end;

   The call to Put_Line can never be made, but it prohibits the
optimizer from deciding that the value of Junk has no effect.

--

					Robert I. Eachus

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

Re: GOTO considered Satanic (was: Is there an ADA analogue to the C++ continue statement?)

[W. Wesley Groleau x4923]

Adam Beneschan wrote:
> The absolutist language ... hardly seems necessary.  

True.

> ...  Programmers
> in the past often turned their code into linguine, but it seems to me
> that this just doesn't happen as often today, 

Not true.  I've seen plenty of pasta-bilities, even in Ada code
with "goto" banned.  One such pasta-bility is to 
set flags all over the place with no documentation of where (or IF)
each flag is used to control a branch.

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: GOTO considered Satanic (was: Is there an ADA analogue to the C++ continue statement?)

[Alan Brain]

Adam Beneschan wrote:
7
> Anyway, my point is: This is the 90's.  The battle has been won.  It's
> no longer necessary to take the attitude that whenever we see a GOTO,
> we should let out a shriek and beat the offending insect to death with
> a broom.  We can, and should, adopt a more moderate and less
> absolutist tone, one that says that GOTO's are generally unnecessary
> and should be avoided but may make code more readable on rare
> occasions.

I wish I could be as sanguine. I've seen some really bad spaghetti
written in modern languages.

The last time I was Software QA honcho on a multi-million line project,
I had to personally sign off on every GOTO used, as being In My
Professional Opinion, necessary.
Didn't have to do it often. I even had to encourage people to use them
on one occasion in a code walkthrough, when the non-GOTO solution was
really, really ugly.

But such a degree of Inertia/Red-Tape is a good way of keeping them to
an appropriate (ie Non-Zero but close to it) level.

-- 
Not the Australian Dairy Farmers Association,
   the Australian Defence Force Academy.
aebrain@dynamite.com.au abrain@cs.adfa.oz.au

Re: GOTO considered Satanic (was: Is there an ADA analogue to the C++ continue statement?)

[Shmuel (Seymour J.) Metz]

Alan Brain wrote:

> I wish I could be as sanguine. I've seen some really bad spaghetti
> written in modern languages.

I've seen some really bad spaghetti with nary a GOtO in sight. Really
convoluted stuff involving deeply nested IFs with boolean flags tested
well away from where they are set and other sorts of highly nonlocal
behavior. Essentially the coders (I hesitate to call them programmers) 
were using a screwdriver as a hammer; not a pretty sight, I might add.
Any control structure is subject to abuse, and anyone doing a code
review
should be as alert to a misused IF as they are to a misused GOTO or to a 
misused global variable.

Some question my use of the term "spaghetti" to describe such code.
However, if I have to skip around in the code to figure out "how did
that variable get set", that's highly analogous to skipping around to
figure out "how did I get here".

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org

Re: Is there an ADA analogue to the C++ continue statement?

[Richard A. O'Keefe]

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

>Algol-60 did not have this construct ['continue'],
> and the algol family generally followed this
>lead. Pascal for instance has no goto, and the one place you will find
>goto used in Wirth's book on algorithms is precisely for the continue
>construct given above (actually that's not quite true, there is another
>place where he uses it for a break out on an exceptional condition, but
>one would be more likely to use an exception for this purpose in Ada.

Pascal _does_ have a goto.  In fact, the Pascal goto can even take you
out of the current subprogram into one of its (lexical) ancestors.
Note that Algol 60 also didn't have a 'while' statement or a 'case'
statement, yet Pascal had both.

-- 
Unsolicited commercial E-mail to this account is prohibited; see section 76E
of the Commonwealth Crimes Act 1914 as amended by the Crimes Legislation
Amendment Act No 108 of 1989.  Maximum penalty:  10 years in gaol.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Is there an ADA analogue to the C++ continue statement?

[John G. Volan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4917 bytes --]


Robert Dewar wrote:
>
> The most reasonable translation [of continue]
> is to introduce a very stylized use of
> the goto for this purpose, putting a label <<CONTINUE>> just before the
> end loop, and then doing a goto to get the effect you want. So we would
> have:
>
>     while Condition_1 loop
>        statement_1;
>
>        if Condition_2 then
>           goto Continue;
>        end if;
>
>        statement_3;
>
>     <<Continue>>
>     end loop;

One difficulty with this: If you have more than one loop within the same
scope which needs to work this way, then you will encounter a name clash
unless you come up with a different label-name for each loop, e.g.:

    while Condition_1 loop
       statement_1;

       if Condition_2 then
          goto Continue_1;
       end if;

       statement_3;

       <<Continue_1>>
          null;
          -- note: a goto-label has to have a statement to hang on
    end loop;

    while Condition_3 loop
       statement_4;

       if Condition_4 then
          goto Continue_2;
       end if;

       statement_5;

       <<Continue_2>>
          null;
          -- note: a goto-label has to have a statement to hang on
    end loop;

This might be a nuissance for some people, just as it would be a
nuissance if we were still living in the age of assembly, where even
simple if-statements required uniquely-named labels.

Then again this could have been worse: If Ada�s rules regarding goto
were more liberal, the practice Robert suggests could have been a source
of bizarre bugs that might have arisen from simple typographical errors:

    while Condition_1 loop
       statement_1;

       if Condition_2 then
          goto Continue_1;
       end if;

       statement_3;

       <<Continue_1>> null;
    end loop;

    while Condition_3 loop
       statement_4;

       if Condition_4 then
          goto Continue_1; -- Oops!
       end if;

       statement_5;

       <<Continue_2>> null;
    end loop;

Luckily, this is illegal. (GNAT generates the error message �target of
goto statement is not reachable�.)

> Final note: for Ada programmers who are incurably goto-challenged, you can
> achieve exactly the same effect as the above loop by using:
>
>    while Condition_1 loop
>    declare
>       Continue : exception;
>    begin
>       statement_1;
>
>       if Condition_2 then
>          raise Continue;
>       end if;
>
>       statement_3;
>
>    exception
>       when Continue => null;

     end; -- need one of these here

>    end loop;
>
> A kind compiler will translate this use of exceptions into a simple goto
> and bypass the normal exception mechanism. Why anyone would go to such
> circumlocutions escapes me, but some programmers will do almost anything
> to avoid the goto keyword, and besides there are silly coding standards
> around which totally forbid the use of the goto keyword.

This scheme avoids the name clash I described above, but there are
coding standards that would consider declaring, raising, and handling an
exception all within the same scope to be just as "naughty" as using a
goto. The argument is that an exception should represent part of the
interface of an abstraction, not part of its internal logic. Basically,
an exception should represent an error situation which the given
abstraction is able to _detect_, but which, by deliberate design, it is
not able to _handle_, because the policy for handling this situation is
beyond its chosen level of abstraction.  Raising and propagating the
exception out of the abstraction leaves it up to its clients to decide
the proper policy.  Otherwise, if the condition is just a "normal"
situation anticipated by the internal logic of the abstraction, then
"normal" control-flow constructs (it is felt) should be good enough.

I agree with Robert that resorting to a goto under these circumstances
is more reasonable and "honest" than "faking" a goto with an exception.
But I would tend to avoid the goto as well, and just live with the extra
level of nesting:

    while Condition_1 loop
       statement_1;

       if not Condition_2 then
          statement_3;
       end if;

    end loop;

    while Condition_3 loop
       statement_4;

       if not Condition_4 then
          statement_5;
       end if;

    end loop;

--
Internet.Usenet.Put_Signature
  (Name       => "John G. Volan",
   Employer   => "Raytheon/TI Advanced C3I Systems, San Jose, CA",
   Work_Email => "jvolan@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using " &
                 "them would be totally erroneous...or is that just "  &
                 "nondeterministic behavior now? :-) ");

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet