🚀 go-pugleaf

In article <4525@crash.cts.com> wade@pnet01.cts.com (Wade Bickel) writes:
>PS:  Please, send me Email if you do not have a solution to the problem I
>        posted, i.e. a lack of the ability to nest subroutines in C.  I had
>        hoped it would be possible, and am quite dissapointed that it is not.
>        At this point I am more interested in how to introduce it into the
>        C language than arguing whether C is better or worse than M2.  How
>        do I make a request to the ANSI commitee?

You must have missed the comments I and others made to the effect that
it is extremely unlikely that this ability will ever be added to C, because
it requires the addition of an expensive mechanism which is hidden from
sight (displays). In C, expense is not to be hidden, and some people
even objected to the addition of structure assignment to the language because
it violated that philosophy!

The way to translate an M2 program that uses nested subroutines is
(as has also been pointed out) to put all the variables in question
into a structure, and pass a pointer to the structure. This is essentially
what M2 does to implement displays behind the scenes. The original structure
should be local (automatic) to the "outermost" routine for recursion to
work correctly. Somebody said that, when they tried that, the result
was unreadable. But that's not *inherent* in this technique; it's possible
to write very readable code this way. Saying foo->list is not that
much worse than just saying "list".

If recursion is not used, then simply using static variables defined
outside that routine suffices, although IMHO it often results in code
that's less readable than the "pass a pointer to a structure" approach.

The nested scoping visibility of routine and variable names cannot
be directly emulated (beyond the one level provided by static-within-a-
source-file), but that is a "syntactic sugar" issue that does not affect
functionality.

Again, I can see how people would really like this nested scoping feature,
but that doesn't mean that C is deficient because it lacks it...it conflicts
with C's design philosophy. "If it ain't broken, don't fix it." So if
you're going to use C, it would be best if you just learned to live with
its philosophy; otherwise you'll be more frustrated than necessary when
working with the language.
	Doug
-- 
Doug Merritt		{pyramid,apple}!xdos!doug
Member, Crusaders for a Better Tomorrow		Professional Wildeyed Visionary