Named Blocks (Was Re: Oh noooooo!!)

[Dave Jones]

>From article <1989Sep7.162909.6638 at light.uucp>, by bvs at light.uucp (Bakul Shah):

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

Just use a "return" to jump out of the procedure, rather than a "goto"
to jump out of the block. Sorry, but I don't see that as an improvement.

But there is a problem you seem to have overlooked. To keep the same
functionality, you are going to have to pass pointers to all local variables
into the newly created procedure, and replace all references to the local
procedures with dereferenced pointers. (C++ "reference" parameters would
save the day, but we're talking C, not C++)

A block of code such as the one under discussion simply does not belong in
another procedure, IMHO.

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

Name one C compiler that does that.

> 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.

We've known a long long time that gotos can be banished with existing
features. But is the cure worse than the complaint? I maintain that
my goto is benign. Creating a new procedure with scads of pointer
dereferences is major surgery.

> 
> On a related note, one feature I miss in C is nested procedures.
>

Sorry, we can't seem to agree on anything. "Nested procedures" is
just the automation of that pointer-creation/dereferencing I talked
about above. Usually there's one pointer for each lexical level,
(the "display"), and each nested procedure indexes off these for
all the "scoped" variables. Phooey on that. (Well, okay, since
we are now in the realm of what might be,  maybe one of
those "modern compilers" could inline the code when appropriate.)

> 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....
> 

At last! Agreement.

This is indeed a problem. But it's a static problem. No need to
bring a runtime display into the picture.

One way to handle it might be a convenient macro mechanism:

      proc_which_would_otherwise_be_too_long()
      {
	int local_var;

        do_some_stuff();
	do_some_more_stuff();
      }

      where macro do_some_stuff() is
      { 
         local_var = 0;  /* Notice, it's still in scope */

         /* blah, blah.. */

         return;   /* We can debate as to whether this returns
                    * from the main procedure or from the macro.
                    * The macro, I think.
                    */
      }
      
It's sort of a cross between a macro and an inline procedure. It is
like a nested-scope procedure, except that it accesses its parent's
variables directly, not through a display, and of course, it can not
call itself or any other "macro" procedure.

Or, I could get by just fine with an editor that could name and
hide blocks, and store such info with the source files. (Hypertext?)
Then you could have this displayed...

      proc_which_would_otherwise_be_too_long()
      {
	int local_var; /* pooh on globals */

        <<do_some_stuff();>>
	<<do_some_more_stuff();>>
      }

If you clicked your mouse on the "do_some_stuff" area, the code would
be expanded there. Click in the expanded area again, and it hides
itself again. (If you work for one of those software companies, please
do not patent this idea. Thank you. I hearby place it in the public
domain.) This would work nicely in conjuction with the named blocks
idea.