🚀 go-pugleaf

>        I do not understand why C does not support Nested routines.  Perhaps
>this will be added to the ANSI standard at some point in the future.

Probably the biggest thing against it is the fact that it makes compilers much
more difficult to write (especially modifying existing compilers).  Nesting
subroutines implies changing the way scoping works (which was always vague in
K&R C).  After that is done, you have to worry about getting the binding
right (which is what link, frame pointer, etc. are for).  After that's done,
you have to go back and fix it since you forgot to get the binding right
for procedure parameters that access variables from an outer frame.

Basically, trying to add this to C is not that easy.  Just adding the scoping
is only syntactic sugar.  IMHO, C fits in between assembler and Modula II,
in that you program at a high level, but your model of the world is still
low level.

Generally, there should be no problem converting back and forth between Modula
II and C.  However, I have run across a case where converting to C was
definately not straight forward.  Basically, in Modula II (actually, a similar
language) procedure A was passed as a parameter to procedure B, who called the
nested routine C.  C would recursively call B.  Whenever procedure A was
called, it needed to use the latest instance of B and C's variables.  This did
not map easily at all to using just local and global variables.  Passing stuff
around in a structures and gobs of parameters sort of worked, but nothing was
readable anymore.  Eventually, I just figured out what the code actually did,
and then rewrote it from scratch in 'C-mode'.  The code was readable, but
no where near as 'elegant' as it originally was.  Some Modula II programmers
are just as hesitant about programming in C as some C programmers are about
programming in assembly; it's all perspective.

Darin Johnson (leadsv!laic!darin@pyramid.pyramid.com)
	We now return you to your regularly scheduled program.