Recent

Author Topic: Eliminating Goto/Label  (Read 5396 times)

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Eliminating Goto/Label
« Reply #15 on: July 19, 2020, 09:23:33 am »
Why not just write procedures  Reload, DispLoop and Lexit? You may define function/procedure within function/procedure.

Because you can't do something like

Code: [Select]
while true do begin
...
  Lexit;
...
  Reload
end;

with code you write yourself, you need language-provided primitives. And it's the use/abuse of those primitives which is being discussed: see the copious code posted by various people.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

egsuh

  • Hero Member
  • *****
  • Posts: 1273
Re: Eliminating Goto/Label
« Reply #16 on: July 19, 2020, 10:39:55 am »
If you have definitive definion of finishing reloading-looping loop, something like following approach should do what you want... of course you have to think over the procedure carefully because each call of functions make stacks.


Code: Pascal  [Select][+][-]
  1. procedure Skeleton;
  2.  
  3. procedure Lexit;
  4. begin
  5.       { Code #14;  }
  6. end;
  7.  
  8. procedure Reload; forward;
  9.  
  10. procedure DisLoop;
  11. begin
  12.       { Code #5 }
  13.       If Condition2 then DispLoop;
  14.       If Condition3 then
  15.           Case VK of
  16.             0:  // Lexit;    ---> This may not be necessary. Lexit will be called at the end of this procedure.
  17.             1:   Begin
  18.                   If Condition4 then DispLoop
  19.                    else begin
  20.                       { Code #6 }
  21.                       Reload;
  22.                    end;
  23.              end;
  24.             2:  Begin
  25.                 { Code #7 }
  26.                 Reload;
  27.             end;
  28.             3:  Begin
  29.                 { Code #8 }        
  30.                 If Condition5 then  Begin
  31.                     { Code #9 }
  32.                      DispLoop;
  33.                  end
  34.                  else begin
  35.                      { Code #10 }
  36.                      Reload;
  37.                 end;
  38.             end;
  39.             4:   Begin
  40.                 { Code #11 }
  41.                 If Condition6 then DispLoop;
  42.                 If Condition7   then  Begin
  43.                       { Code #12 }
  44.                       Reload;
  45.                     end
  46.                    else DispLoop;
  47.               end;
  48.             5:  Begin
  49.                 { Code #13 }
  50.                 DispLoop;  
  51.              end;
  52.        end; {Case}
  53.  
  54.        Lexit;      
  55. end;
  56.  
  57. procedure  Reload;
  58. begin
  59.       { Code #4 };
  60.  
  61.       DisLoop;
  62. end;
  63.      
  64.  Begin    // of procedure Skeleton
  65.       { Code #1 }
  66.       If Condition1 then
  67.         Begin
  68.             { Code #2 }
  69.             Lexit;
  70.             Exit; // Not sure whether this is necessary here.
  71.         end;
  72.       { Code #3 }
  73.      
  74.       Reload;
  75. end;
« Last Edit: July 19, 2020, 06:08:50 pm by egsuh »

kupferstecher

  • Hero Member
  • *****
  • Posts: 583
Re: Eliminating Goto/Label
« Reply #17 on: July 19, 2020, 12:07:49 pm »
I'm fairly relaxed about goto, there are cases where it's quite simply the right tool for the job. Just don't over-use it.
I'm also relaxed about goto, but I didn't use it in the last several years, I never saw the necessity.

Even if goto would be the ideal solution in on specific case... the code often has to be changed afterwards which may destroy the perfection. And then rearranging such "optimised" code is quite an effort.

E.g. I also quite seldom use for-in-loops. Although I very like the concept and it makes the loop bounds very save, but it happened so often to me that later I needed a loop iterater in the same loop or I had to assign to the indexed variable which is not allowed in a for-in. And also not seldom I changed the loop again, so the for-in, again, would be the better option.

process_1

  • Guest
Re: Eliminating Goto/Label
« Reply #18 on: July 19, 2020, 12:45:51 pm »
@MaxCuriosus

What you basically do is to display data in the loop, ocassionally reload (whatever), then the simples (at least for me) is following approach:

Code: [Select]
procedure Skeleton;
  isReload: Boolean;

begin
  { Code #1 }
  if Condition1 then
  begin
    { Code #2 }
  end
  else
  begin

    { Code #3 }

    isReload := True;

    while True do
    begin

      // Reload:

      if isReload then
      begin
        { Code #4 }
        isReload := False;
      end;

      // DispLoop:

      repeat
        { Code #5 }
      until not Condition2;

      if Condition3 then
      begin

        case VK of
          0: break;

          1:
          begin
            if Condition4 then
              continue;

            { Code #6 }
            isReload := True;
          end;

          2:
          begin
            { Code #7 }
            isReload := True;
          end;

          3:
          begin
            { Code #8 }
            if Condition5 then
            begin
              { Code #9 }
              continue;
            end;

            { Code #10 }
            isReload := True;

          end;

          4:
          begin
            { Code #11 }
            if Condition6 then
              continue;

            if Condition7 then
            begin
              { Code #12 }
              isReload := True;
            end;

          end;

          5:
          begin
            { Code #13 }
          end;

        end; {Case}

      end; {If Condition3}

    end;

  end;

  //Lexit: ;
  { Code #14 }
end;


MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Eliminating Goto/Label
« Reply #19 on: July 19, 2020, 01:35:51 pm »
Nobody denies that GOTO can be always be replaced, with varying degrees of inelegance.

The issue is whether it's worth it.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

process_1

  • Guest
Re: Eliminating Goto/Label
« Reply #20 on: July 19, 2020, 01:45:53 pm »
Well, the main point of this is that ASM style of progamming in higher languages need to be avoided by any cost. It is real headache for maintenence and clear sign for any employer what to do with such programmer.
« Last Edit: July 19, 2020, 02:18:11 pm by process_1 »

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Eliminating Goto/Label
« Reply #21 on: July 19, 2020, 03:00:00 pm »
That is your opinion. It is not mine.

If a GOTO with strictly defined locality and adequate documentation is the most elegant and intuitive way of doing something, then I consider it to be acceptable.

I'm far more bothered about setjmp() etc. than I am about GOTO, on account of its implicit temptation to jump across block boundaries.

If the block in which a GOTO is syntactically valid is too big to make it obvious what's going on then that is obviously a problem in itself.

I am emphatically not saying that GOTO is acceptable in a context where it could be trivially replaced by repeat/until or some comparable construct. But I don't call introducing loads of single-use Boolean flags "trivial".

I'd also remind you that some hold the belief that since GOTO is "considered harmful" then BREAK, EXIT etc. should also be deprecated.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

howardpc

  • Hero Member
  • *****
  • Posts: 4144
Re: Eliminating Goto/Label
« Reply #22 on: July 19, 2020, 03:34:03 pm »
Often higher-level Break, Continue and Exit commands are implemented at assembly level by the compiler's code generator using gotos (jmp etc.).
So, like many generalisations, the proverbial wickedness of GoTo, and the need to avoid it, is merely hidden or disguised by high level language constructs, but not ultimately avoided.
GoTo is not intrinsically evil. But it is a construct that is so easily abused to write spaghetti code. Of course, spaghetti can also easily be produced without any gotos.

process_1

  • Guest
Re: Eliminating Goto/Label
« Reply #23 on: July 19, 2020, 03:41:13 pm »
@MarkMLl

Well, it is not my opinion it is general attitude in programming. Using LABELS and GOTO is considered bad practice in higher languages. These are stuff kids today first learn in school or university.

As a senior programmer (almost retired) which is practically grown on ASM, I do support such attitude that it should be avoided by any cost in higer language, while in ASM that is "natural".

Even more, nowadays compilers makes quite well optimization that such code "complication" to avoid usage of lablels and goto in higher languages, actually is minimum lost or even non existed.

Thus, no need to make source code more complicated than it really is. This may be acceptable in some cases, but certainly shouldn't be a practice.

One parallel. Toyota had an accident some 5 years ago or so with unpredictable car acceleration which was consequance of extensive use of recursion in the software (leading stack overflow, IIRC), which is even strictly forbiden by MISRA standards.

Avio industry also suffer from badly implemented software and "glitches" may cost several hundred lives...

Thus, some rules need to be followed as there is great chances that badly designed and implemented software cost even lives. Fine is we programming for fun, but in industry that is very serious matter.

devEric69

  • Hero Member
  • *****
  • Posts: 648
Re: Eliminating Goto/Label
« Reply #24 on: July 19, 2020, 03:58:06 pm »
It's understandable, and to their credit, that the MISRA standards are against a stack overflow.

Concerning myself, i really prefer to read in nested loops "If Not bAllRight Then goto NextThis;" rather than "If Not bAllRight Then Continue;".
use: Linux 64 bits (Ubuntu 20.04 LTS).
Lazarus version: 2.0.4 (svn revision: 62502M) compiled with fpc 3.0.4 - fpDebug \ Dwarf3.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Eliminating Goto/Label
« Reply #25 on: July 19, 2020, 04:03:40 pm »
Well, it is not my opinion it is general attitude in programming. Using LABELS and GOTO is considered bad practice in higher languages. These are stuff kids today first learn in school or university.

They're also taught that C++ and Javascript are a good idea. And they used to be taught that APL was a good idea, with absolutely no consideration of the runtime resources required. And Lisp, Prolog and Smalltalk with no security in their runtime storage. I can play this game for hours... :-)

Quote
As a senior programmer (almost retired) which is practically grown on ASM, I do support such attitude that it should be avoided by any cost in higer language, while in ASM that is "natural".

As an engineer who /ought/ to be close to retirement, I'd argue that a pragmatic approach is to be preferred. And that it's very often appropriate to use block-structured constructs in assembler programming.

Quote
One parallel. Toyota had an accident some 5 years ago or so with unpredictable car acceleration which was consequance of extensive use of recursion in the software (leading stack overflow, IIRC), which is even strictly forbiden by MISRA standards.

Except where the events were due to out-of-place floor mats or provably-inept drivers. But I agree that wilfully ignoring documented standards is a very big problem... which is an argument for keeping documentation and standards simple and then enforcing them mercilessly (which would avoid debacles like "dieselgate" and the deaths due to an undocumented spring change in (Delco?) ignition switches).

And since you mention recursion I'd point out that a whole lot of people who use it probably don't do so knowingly, because they lack the background to understand exactly what the compiler and runtimes are doing on their behalf. I could go on...

Quote
Thus, some rules need to be followed as there is great chances that badly designed and implemented software cost even lives. Fine is we programming for fun, but in industry that is very serious matter.

But again, that argues: keep things simple and intelligible. So if you can do it in five statements plus comments pointing out why you're using a GOTO, it's preferable to using 15.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Eliminating Goto/Label
« Reply #26 on: July 19, 2020, 04:05:13 pm »
Concerning myself, i really prefer to read in nested loops "If Not bAllRight Then goto NextThis;" rather than "If Not bAllRight Then Continue;".

GRIN

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

process_1

  • Guest
Re: Eliminating Goto/Label
« Reply #27 on: July 19, 2020, 04:21:22 pm »
It's understandable, and to their credit, that the MISRA standards are against a stack overflow.

You are probably not aware on what people are ready to do to save  few cents on hardware (ie maximizing profit) and try to "fix" issues in software, making things even worst. Human lives? Nah, they have bunch of lawyers to cover anything... These mentioned examples are self-explanatory.

And this is as well quite interesting,not far from future massive use:
https://www.youtube.com/watch?v=y3RIHnK0_NE

We are doomed, no doubt! ;)

Warfley

  • Hero Member
  • *****
  • Posts: 1499
Re: Eliminating Goto/Label
« Reply #28 on: July 19, 2020, 04:27:09 pm »
I do support such attitude that it should be avoided by any cost in higer language
This statement (i.e. avoid goto by any cost) implies that you are happy to replace:
Code: Pascal  [Select][+][-]
  1.     label foo;
  2.     begin
  3.       ...
  4.       goto foo;
  5.       ...
  6.     foo:
  7.       ...
  8.  
with this
Code: Pascal  [Select][+][-]
  1.     type TGotoFooException = class;
  2.     begin
  3.       try
  4.         ...
  5.         raise TGotoFooException.Create;
  6.         ...
  7.       except on e: TGotoFooException do;
  8.       end;
  9.       ...

And I personally don't know anyone who would bring forth that argument.

Goto is not intrinsicly bad, goto often leads to less readable code, but, if you replace goto with something that is even less readable, you just made your code worse, even though you got rid of goto.

Quote
One parallel. Toyota had an accident some 5 years ago or so with unpredictable car acceleration which was consequance of extensive use of recursion in the software (leading stack overflow, IIRC), which is even strictly forbiden by MISRA standards.
[...]
Thus, some rules need to be followed as there is great chances that badly designed and implemented software cost even lives. Fine is we programming for fun, but in industry that is very serious matter.
Yes, but most people don't write safty crucial software for the automobile industry. If a car crashes because of a software bug it results in a lot of damage, including human damage. This must be avoided even at very low risks. If the size calculator for an online shop crashes and the customer has to reload the page, it is annoying but if it doesn't happen to often no one bats an eye.

Very ofter a recursive solution is the easiest solution, and saying that you need to invest a lot more time to change this function for in an online shop software to be iterative because in the automobile industrie this could result in human casulties is a little bit far fetched.

And this might not even be the general case, look at functional languages like Haskell, Haskell can't be used without recursion, and in haskell there is no such thing as a stack overflow (because in haskell there is no such thing as a stack).

These rules are dependent on their context, and while they may be very sensible in the automobile or avionics industry, for your run of the middle webdev or app developer they are simply restricting you, without you gaining anything, because no one cares if your app crashes occasionally as long as most of the time it works fine.

Also, optimizing tail recursion to an iterative function is one of the baseline optimizations most compilers do. So simple recursion will actually be compiled to iterative code anyway
« Last Edit: July 19, 2020, 04:29:00 pm by Warfley »

process_1

  • Guest
Re: Eliminating Goto/Label
« Reply #29 on: July 19, 2020, 04:53:56 pm »

This statement (i.e. avoid goto by any cost) implies that you are happy to replace:
...
with this
...

That is plain insinuation - that is your code! ;)
I would never wrote such code, especially not with raise. ;)

But certainly, GOTO and LABELS are just relicts from the ASM...

As I have wrote already, if we make software for fun - who cares? But developing good habbit in programming is crucial for eventual professional carriere, especially for safty critical products. Embedded programming is quite popular nowadays and MCUs are quite powerful and cheap, but they simply have significantly less resources than classical desktop computer. Thus, lazy programmers used to recursion everywhere have nothing to do in that world...

Programming used to be art long time ago, but nowadays...
« Last Edit: July 19, 2020, 05:04:06 pm by process_1 »

 

TinyPortal © 2005-2018