since "goto"s are unequivocally unacceptable to me,
"Please don't fall into the trap of believing that I am terribly dogmatical about [the goto statement]. I have the uncomfortable feeling that others are making a religion out of it, as if the conceptual problems of programming could be solved by a single trick, by a simple form of coding discipline!"
Why?Because the target destination of a goto can be anywhere in the function/procedure. IOW, its destination needs to be determined by searching for the target label (which can be anywhere in the function/procedure, not necessarily in the case statement, that's a problem.) When a programmer reads a "goto xyz" statement, it provides no information whatsoever as to where the destination "xyz" is.
Because the target destination of a goto can be anywhere in the function/procedure. IOW, its destination needs to be determined by searching for the target label (which can be anywhere in the function/procedure, not necessarily in the case statement, that's a problem.) When a programmer reads a "goto xyz" statement, it provides no information whatsoever as to where the destination "xyz" is.
Additionally, a goto, requires defining labels and manually keeping the labels "in synch" with the cases. That's makes maintenance more difficult and error prone, not to mention that declaring a bunch of labels is tedious. Pascal has enough deterministic control flow features to make the "goto" statement completely unnecessary, therefore a deficient solution.
Would it be feasible for the compiler to allow a goto to target a (numeric) destination in this situation?
Both of which I propose removing.I am unclear as to what things you are proposing removing. Can you be explicit on what they are ?
In Pascal it either requires nested ifs or goto.It can be done in FPC/Delphi without if(s) and without goto(s) but, "lesser" forms of Pascal may require either or both.
When doing low level programming, jumping tables are essential,
jump tables, format tables, substitution tablesYou mean Birthday parties, Christmas tables and finding eggs in the garden?
I have ~ two pages of a single CASE statement using a GOTO loopback
This process decodes a serial stream of digital data that can be incomplete with the current cached data and thus sets the GOTO loop to resume where it was.
Also, this large CASE plays the role of a C style switch whereas it changes the CASE switch to process to the next in line switch and uses a GOTO back to the loop, again.
If for some reason the current CASE index cannot be completed it just allows the case to exit as normal but keeps the current CASE index to pick up for the next time.
This logic was very hard to process using IF statements and the like, it was much easier using a C style Case switch.
I have ~ two pages of a single CASE statement using a GOTO loopback
This process decodes a serial stream of digital data that can be incomplete with the current cached data and thus sets the GOTO loop to resume where it was.
Also, this large CASE plays the role of a C style switch whereas it changes the CASE switch to process to the next in line switch and uses a GOTO back to the loop, again.
If for some reason the current CASE index cannot be completed it just allows the case to exit as normal but keeps the current CASE index to pick up for the next time.
This logic was very hard to process using IF statements and the like, it was much easier using a C style Case switch.
Yes, very much my rationale. In effect goto is overloading the selector value and going back to the start of the case: very much like continue does with a while.
MarkMLl
BTW, I don't miss that particularity of the C-switch, besides one very special case of https://forum.lazarus.freepascal.org/index.php/topic,60218.msg450448.html#msg450448
The goto statement can already target numeric destinations, however these need to be declared as a label nevertheless and that will stay, because Pascal is a language where things need to be declared before use.
Perhaps he meant with numeric goto that you could address the label indirectly
...the branches of a case-statement are not labels, because they can be ranges as well and thus even if non-declared labels could be used you still can't target the branches of a case-statement with that.
Or, as Zvoni wrote, in that particular case with an extra check:My statement was more along the lines of
@Fallthrough:It is my misunderstanding, I thought you've meant to merge cases (the fall through case and the previous one) and then to use if-then to split them again in the compound operator.
Huh? Just use consecutive If-Then with an Else-Clause for the last if
If you need to exit the "switch" prematurely move the whole thing to a Function/Procedure
The goto statement can already target numeric destinations, however these need to be declared as a label nevertheless and that will stay, because Pascal is a language where things need to be declared before use.
Perhaps he meant with numeric goto that you could address the label indirectly
Ahhh….. ok, now i understand.@Fallthrough:It is my misunderstanding, I thought you've meant to merge cases (the fall through case and the previous one) and then to use if-then to split them again in the compound operator.
Huh? Just use consecutive If-Then with an Else-Clause for the last if
If you need to exit the "switch" prematurely move the whole thing to a Function/Procedure