What I thought was a simple question has sparked off some wild
speculation that may distract attention from the real issue. I merely
wish to enquire why it is thought necessary to remove a feature of the
language that is the simplest solution to a particular kind of
problem.

Only Bertrand Meltz, in his latest posting, seems to have grasped the
point. Thanks!

At 11:02 on 14 January, Yasuki Arasaki wrote:

 > 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, ...)
 > etc

Not at all. The code in question is in an inner loop. Depending on the
value of index in a particular cycle of the loop, some of the code
need not be executed.

At 10:22 on 14 January, Hargraves Gary wrote:

 > Having also had the benefit of a number of response postings, I
 > offer the following comments:
 >
 > *       Overall, the problem being addressed by the code might
 >         benefit from some broader restructuring (requiring more
 >         knowledge than currently conveyed)

Always a possibility, but not the point of my question.

 > *       It would appear on the evidence, however, that porting to
 >         standard compliant ... and not obsolescent ... code with as
 >         little trouble as possible is the object of the exercise

Not true either. I can convert it to standard-compliant code in
various ways with very little trouble. The point is quite simply that
the computed GOTO provides a straightforward way to do the job, and
the various compliant options all seem to me to be clumsier and less
transparent to the human reader. They also require the overhead of
additional tests, though that isn't a major issue.

 > *       For that reason, the 'if then ... else if ' type structure
 >         would be the one for the job - as only one successful test
 >         results in clause execution, and there is an option for a
 >         default clause ('else')

But it's cumbersome by comparison.

 > *       One might consider, of course, putting the most populous
 >         (likely) case first - if this is of assistance in improving
 >         overall speed

Irrelevant to this problem.

 > *       The very laudable suggestion of routine calls within each
 >         clause is supported - but falls into the category of dot
 >         point one above

This brings in the overhead of subroutine calls, and for an inner loop
is much worse than the extra tests needed for the simpler solutions.

--
Anthony Stone                           http://www-stone.ch.cam.ac.uk/
University Chemical Laboratory,         Email:   [log in to unmask]
Lensfield Road,                         Phone:  +44 1223 336375
Cambridge CB2 1EW                       Fax:    +44 1223 336362