Named Blocks (Was Re: Oh noooooo!!)

[Bakul Shah]

In article <475 at thirdi.UUCP> peter at thirdi.UUCP (Peter Rowell) writes:
>In article <7598 at goofy.megatest.UUCP> djones at megatest.UUCP (Dave Jones) writes:
>...
>>I just now produced one [a benign goto] ...
>...
>>  while(rule = (Rule*)Queue_iter_next(&rule_iter)) {
>>    ...
>>    while(rsym = (Symbol*)Queue_iter_next(&rsym_iter)) {
>>    ...
>>	switch (derives(rsym)) {
>>	case derives_nothing:
>>	  goto next_rule;
>>	}
>> ...
>>    }
>> ...
>>  next_rule: continue;
>>  }
>
>I agree with David, since in C there really aren't any beautiful ways
>to do the above.
>
>One thing I would have loved to have seen introduced by ANSI would have
>been "named blocks", but I am sure that parsing them is a bitch.
>
> [a version of the above example using named blocks]

Note that the `benign' goto above can be removed also by use of a
procedure.  It can also improve readability (which is the underlying
theme here).

    static foo(rule) {  /* rename `foo' to something better */
      ...
      while(rsym = (Symbol*)Queue_iter_next(&rsym_iter)) {
	...
	switch (derives(rsym)) {
	case derives_nothing:
	  return;
	}
      }

    caller_of_foo(..) {
      ...
      while(rule = (Rule*)Queue_iter_next(&rule_iter)) {
	...
	foo(rule);
      }
    }

I find short procedures and ones with simple control structues easy
to read.  But ones using nested loops and control jumps to various
levels of switches and loops are hard to grasp.  Breaking an inner
loop into a separate procedure (hopefully) forces one to think about
making the connection between the caller and callee relatively thin.

Also note that modern compilers are capable of inlining such one
time use procedures (with a little help from the user).

This is not to argue merits of named blocks but to point out that
existing features are not only capable of banishing gotos but can
also improve readability.

On a related note, one feature I miss in C is nested procedures.
Without them one ends up using global variables or passing lots of
arguments or avoids using a procedutre altogether because the code
that can be broken off into a separate procedure is just too tightly
coupled with its environment and would make for a very messy
interface (or force global var usage).  Oh well....

-- Bakul Shah <..!{ames,sun,ucbvax,uunet}!amdcad!light!bvs>