My guess is that the original code restarts an interrupted job,
with "index" holding how far the job has run so far (and saved on
disk between the chunks labeled 110, 109, ...) We want to do that
sort of thing often enough why wouldn't popular operating systems let
us do that without explicitly coding for it? :-(
Anyway, if that's the case, the computed GOTO is not really part of the
main program logic but is there only as sort of a quick fix. No wonder
it doesn't translate obviously to a modern control structure.
A generalization of the code that justifies use of structured
constructs might be to introduce a new array holding what to do
into Keith Refson's solution (might as well make it character):
i=index
do
select case(what_to_do(i))
case ("Initialize")
.. stuff
case ("Compute A")
... more stuff
case ("Print B")
...
case ("Quit")
exit
end select
i=i+1
end do
The what_to_do array might be read from an input file for more
flexibility (compared to the fixed sequential flow in the computed GOTO
example) like intentionally skipping parts of the computation
or choosing alternate algorithms. Now the loop and case is a natural
part of the program logic. "index" can then be used to skip
what_to_do(1:index-1) in case of a restart, and computed goto is no
longer a simple solution. Good structured coding justified :-)
--
Yasuki Arasaki
[log in to unmask]
