(j3.2006) Obsolescent stuff -- was in the corrigendum thread

[Van Snyder]

Malcolm Cohen wrote:
> ...
>   
>> The argument is that computed GO TO ought to be replaced by SELECT CASE.
>> Well, the code is a coroutine.
>>     
>
> I think this is precisely the case when computed GOTO is superior to SELECT CASE.
>   

In the past to transform such codes to use SELECT CASE, I've identified 
the basic blocks, or constructs if there are any, and given each one a 
different number.  Then I put a SELECT CASE construct inside a DO 
construct, with each basic block or construct in a different CASE 
<block>.  Each <block> ends by assigning the number of the next <block> 
to the state variable in the SELECT CASE statement, and then, if 
user-code is needed, returning.  The state variable is in the calling 
sequence, perhaps as a component of an argument that holds what would be 
an activation record in a real coroutine.  Sometimes several basic 
blocks and constructs can be strung together inside one CASE <block> in 
the SELECT CASE construct.  This looks like it's well-structured because 
it doesn't have any GO TO statements, but the flow is frequently more 
difficult to understand than the GO TO version

>> I'm afraid to make a massive reorganization of it, for fear that it will
>> be ten years before we discover the bugs thereby introduced.
>>     
>
> Any reorganised version would almost certainly not be better-structured, and might well be significantly worse-structured.  I would leave it alone if I were you!
>   

If we had coroutines I would reorganize the code, but not until then.  
As a coroutine, the code could be as well-structured as one that 
accesses user code by way of dummy procedures.