C Wish List

[COTTRELL, JAMES]

/*
> > 	4. Allow true block structuring:
> > 
> > 		outs(s) char*s; {
> > 			outc(c) char c; {...}
> > 			tputs(s, outc);
> > 		}
> 
> Let's call this "nested procedures" since C has its own sort of block
> structure.  I would be very happy <<never>> to have to deal with nested
> procedures again.  (I have had to deal with them more from the compiler-
> writer's side than from the user's side.)  Nested procedures are neither
> easy nor cheap (unless done wrong, which happens often enough).  They fight
> particularly with procedure variables, which I consider to be one of C's
> more useful features (and a moderately serious shortcoming of Pascal).

Yes, a `proc' or `func' keyword would almost be mandated.
 
> First, what are the advantages of nested procedures?  Two main ones:
> 
> 	Procedure hiding--Inner procedures are local to the outer one,
> 	which keeps them out of the scope of people who shouldn't be using
> 	them--but there are better ways to get this protection, and the
> 	nesting (contour model) isn't necessarily the best anyway.
> 
> 	Access to intermediate variables--the locals of an outer procedure
> 	are global to inner procedures.  There are more arguments that
> 	use of this mechanism leads to hard-to-read code than that it is
> 	useful.

It would be hard to read only if the funxions were big, & split across
pages. Most of us turn to the beginning of the file to find global vars
but with this scheme we would have to check the enclosing funxions first.
Of course, the way most people program, we would be faced with the worst.

> Second, what are the costs?  The major cost is that it is necessary to
> maintain the static linkage of procedures--a record of which stack frames
> from outer levels are accessible at inner levels.  Either it has to be
> maintained by updating at each procedure call (which makes procedure calls
> much more expensive than a jsr or so) or it has to be dug out in order to
> access intermediate variables.  Worse, when you pass a procedure as a
> parameter, you have to pass the static chain along with it.  This means
> either a reference to static chain information stored somewhere, with
> beaucoup magic to reference intermediate variables, or you carry the entire
> static chain with you; procedure objects get large and you have to present
> an edict on the maximum static nesting of procedures.

Oh god, I hadn't even thought of all that! At first, I thought it would
be relatively easy to calculate the static offsets for the enclosing
funxion's local vars, but then what if B & C are nested within A?
Suppose Z calls A, which calls B, which then calls C. Now how does
C get to A's local vars? Yuk!

Of course, noone says C's stack frame (as we know it) is sacred. We
could use a lisp-like binding stack, but then we'd have to include
the names (or generated equivalents) as part of the stack & search it to
find the most recent binding. And people complain NOW about call overhead!
 
> The worst of it is that <<nested procedures are seldom necessary>> IF a
> language provides other hiding mechanisms.  Simple as it is, C's rule for
> limiting the scope of static objects to a compilation unit is entirely
> adequate for this sort of hiding.

How true! Searchlight casting for faults in the clouds of delusion!
I too have seen the studys that indicate that even when this facility
is provided it is seldom used. And yes, C provides you at least two
levels of nesting. One at the funxion level (auto vs extern), the other 
at the file level (static vs ""). More levels are seldom needed.
In fact, another level comes to mind, that of using #defines to 
invalidate funxion names beyond their scope:

#define g @#$%
f(){	/* can't call g here or we get syntax error */
}
#undef g
g(){
}
h(){	g();
}
#define g @#$%
j(){	/* can't call g here either */
}

Of course, this isn't perfect, as f should be able to call an external g().

> Dick Dunn	{hao,ucbvax,allegra}!nbires!rcd		(303)444-5710 x3086
>    ...At last it's the real thing...or close enough to pretend.

I'm still walking, so I'm sure that I can dance...

	jim		cottrell at nbs
*/
------