Re: Problems/Risks ...

Re: Problems/Risks ...

[Mark Oestmann]

In Message-ID: <5432@crdgw1.crd.ge.com>
Richard A Hammond writes:
> What other programming language?  Only one without any GOTO or restricted
> GOTO (e.g. exit, break, ...).  This leaves out Ada!!!!!!
> 
> Similar bug in Ada:     (Cut down for posting, but gives the flavor)
>
> procedure test is
>         MAX : constant := 10; 
>         type t is array(positive range 1 .. MAX) of boolean; 
>         NEW_ITEMS : t; 
>  
>     begin 
>         for N in 1 .. MAX loop 
>             case ...
>             when ... =>
>                 if NEW_ITEMS(N) = FALSE then 
>                         -- some other useful work gets done here
>                         exit;                   -- exits loop, not if!
>                 end if; 
>             when ... =>
>             end case;
>         end loop; 
>     end test;
> 
> So, in the AT&T case using Ada we would have exited both the switch and the
> loop rather than just the switch.  Hardly an improvement!
> 
> More generally, I find it distressing that the advocates of Ada are
> failing to distinguish between language independent features and language
> dependent features in assigning credit for software improvements.

I agree, somewhat.  
Both Ada and C require a huge dose of software engineering and good coding
practices to make them work properly.
Good coding practices dictate that destination of the transfer of control
should be explicitly specified.  In Ada this may be done in any 
type of loop (The Ada 'exit' statement exits ONLY from a loop.) by naming
the loop:


  TELEPHONE_LOOP:
  for Counter in Telephone_Type
  loop
    -- executable code
    if Some_Condition then
      -- executable code
    elsif Some_Other_Condition then
      -- executable code
    else
      exit TELEPHONE_LOOP;
    end if;
    -- executable code;
   end loop TELEPHONE_LOOP;

The same thing could be done in C by giving a name to the loop or switch
in a comment preceding the loop or switch.  The name of this loop or switch
would also appear in a comment following the 'break' statement.  The only
drawback would be that the intent of the programmer is not necessarily
fulfilled by the compiler if there existed a innermore loop or switch.

AS PERTAINS TO THE Ada 'GOTO':

It is not needed.  Our Software Engineering program is one year in length 
and has Ada as the core language.  The students do not hear the word 'GOTO'
as pertains to Ada until the day of graduation.  My parting shot to them is,
"By the way, Ada does have a 'GOTO'. Don't use it."

Granted, the ability to foul up a program is available in Ada as well as
in C or any other language.  

Naming exited loops (or switches) and never using 'GOTO's are two of many
good coding practices that help eliminate software errors.  Adherence to 
software engineering principles and good coding practices is the only
solution to our problems.

Mark Oestmann
School of Engineering and Logistics
Red River Army Depot
Texarkana, TX  75507-5000

-------

Re: Problems/Risks ...

[David Kassover]

In article <12568231436.32.MOESTMANN@WSMR-SIMTEL20.ARMY.MIL> AMXMC-SEL@WSMR-SIMTEL20.ARMY.MIL (Mark Oestmann) writes:
>
>AS PERTAINS TO THE Ada 'GOTO':
>
>It is not needed.  Our Software Engineering program is one year in length 
>and has Ada as the core language.  The students do not hear the word 'GOTO'
>as pertains to Ada until the day of graduation.  My parting shot to them is,
>"By the way, Ada does have a 'GOTO'. Don't use it."
>
Oh wow.  Another structured programming debate.  Sorry, I'm
showing my age 8-).
 
Eliminating the GOTO does not eliminate all unconditional
transfers from Ada.

Ada is functionally complete without the GOTO.  There is no
program that could not be written without it.  BUT in some
circumstances the cost of programming around the unconditional
transfer is high.  (Retesting a condition?  when that condition
is REAL-TIME and not likely to be in the same state?  Reading to
the end of a 40 Gigabyte data set (don't laugh, please, such
exist) when it is already determined that such is futile?)
 
There are GOTOs in my Ada code.  A lot less than there would be
if I were using FORTRAN.  But I use them carefully.
 
Textbook cases used for pedagogical purposes are generally very
simple when compared to many real life programs.  Ignoring the
"hard" or "pathological" cases is not a good way to go.


Hmm.  I'm away from my Kernighan and Ritchie.  But doesn't C have
a GOTO statement, too?  Not to mention the trinary operator,
which helps produce unreadable one-line wonders, and by the way,
compiles into inferior machine code using VAX C.  (inferior to
just writing out the IF-THEN-ELSE like normal people  (only have
a grin here))

Re: Eliminating the GOTO

[William Thomas Wolfe, 2847]

From kassover@jupiter.crd.ge.com (David Kassover):
> Ada is functionally complete without the GOTO.  There is no
> program that could not be written without it.  BUT in some
> circumstances the cost of programming around the unconditional
> transfer is high.  (Retesting a condition?  when that condition
> is REAL-TIME and not likely to be in the same state?  Reading to
> the end of a 40 Gigabyte data set (don't laugh, please, such
> exist) when it is already determined that such is futile?)

   There was a paper recently (I saw the abstract listed in CACM
   within the past 12 months or so) which published an effective
   procedure for mechanically transforming any program having GOTOs 
   into an equivalent program using the loop...exit construct.  I'd
   suspect that there would not be any loss of efficiency involved...


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: Problems/Risks ...

[John F Nixon]

kassover@jupiter.crd.ge.com (David Kassover) writes:
>Oh wow.  Another structured programming debate.  Sorry, I'm
>showing my age 8-).

me too... ;-)

>Ada is functionally complete without the GOTO.  There is no
>program that could not be written without it.

Of course, this holds for any language with sequential, conditional, and
iterative statements.  Like FORTRAN77.

>BUT in some circumstances the cost of programming around [an] unconditional
>transfer is high.

Do you mean the run-time cost, or the write-time cost?  I would
think that if you find the need to program around an unconditional transfer,
one should probably scrap the section in question and write it again
(with the proviso that error handling may require a goto to common cleanup
statements...).

>But doesn't C have a GOTO statement, too?

Yeppers.

>Not to mention the trinary operator, which helps produce unreadable one-line
>wonders, and by the way, compiles into inferior machine code using VAX C.

OK, I won't mention it... :-).  BTW, VAX C is an inferior conpiler, period.

----
jnixon@atl.ge.com                    ...steinmetz!atl.decnet!jnxion

Re: Problems/Risks ...

[David Kassover]

In article <205@puma.ge.com> jnixon@andrew.ATL.GE.COM (John F Nixon) writes:
>...
>OK, I won't mention it... :-).  BTW, VAX C is an inferior conpiler, period.
>

Not if you happen to have VAX hardware.  For that matter VAX C is
completely portable between VMS and Ultrix, if you haven't made
any (direct) RTL or system service calls.
 
Are we gonna discuss RISC vs. CISC now, too?  8-)