🚀 go-pugleaf

In article <4501@crash.cts.com> wade@pnet01.cts.com (Wade Bickel) writes:
>        I do not understand why C does not support Nested routines.  Perhaps

After going to the trouble to write an article explaining this yesterday,
I find that I neglected to post it. Here it is:

In article <4495@crash.cts.com> wade@pnet01.cts.com (Wade Bickel) writes:
>shadow@pawl.rpi.edu (Deven T. Corzine) writes:
>>One midpoint approach is to put the data values in a structure, and
>>pass a pointer to the structure.  This still involves passing an extra
>>parameter, but avoids duplicating the data unnecessarily.  Another
>
>        I've considered this, but it will make what was an easy, maintainable
>codeing trick into a mess.

Not at all. The syntactic sugar of nested function definitions is
sometimes nice, but at other times actually *harder* to follow than
the "pass an extra parameter" approach. (Hmmm, now *which* 'foo' is being
used here?)

In any event, fully block structured languages support nested definitions
via "displays", which amount to the same thing as an extra parameter,
but maintained by the compiler, and integrated with the usual scoping
rules. The major complaint about Displays is that they are relatively
expensive to implement at run time, yet the expense is hidden by the
language.

This can be a blessing if you would've used the "extra parameter" approach
anyway, but it's a curse to the (large) extent that Displays are used
needlessly at times they aren't really needed, leading to noticeable
decrease in speed. And again, they are very frequently misused in terms
of readability.

Given the design goals of C (which I would off the cuff state as "give
high level support to all of the basic low level constructs needed for
systems programming, in a way that is easy to understand the cost, so
that C code can be very easily made efficient by the programmer"), clearly
Displays don't fit in, because they can be very easily emulated (note
that C does not support dynamic data structures like linked lists
directly either), and basically their whole purpose is to hide a construct
whose expense "should" remain exposed.

>Nested subroutines prevent spagetti code, which is very common in C.

False. Programmers create spaghetti code in all languages, and all biases
aside, Modula 2 programs are *in general* no more (nor less) readable than
C. This kind of claim is frequently made about languages, when what is
really at issue is relative familiarity or small differences in convenience.

>        So I thought as well.  I too really like the tersness of C.  However
>I have now found something of major significants which I can do in M2 but not
>in C.

Ada has features that neither C nor Modula 2 have, why not switch? :-)
Seriously, you have to make up your mind what you want. If you want
a very easily optimized systems programming language, C wins. If what
you want is high level support for abstractions in order to make you a more
efficient programmer, why settle for Modula 2?

Both C and Modula 2 are what *I* would call very low end high level
languages. By comparison, Smalltalk, FPL, Scheme, Icon, and even Ada
give much better support for higher level abstractions. Thus the whole
notion of "C versus Modula 2" is a tempest in a teapot...compared with
other languages, they're practically identical!

>I used to wonder as I would translate C to M2 why globals were so heavily
>used, often wondering if this was a sign that the programmer was of
>questionable talent, leading me to re-organize/re-write the code.  Now I see
>why this is done.  Very UGLY :^<

You were 80% right the first time; most programmers (using any language)
have questionable talent and use globals unnecessarily. But note that
the right way *in C* to handle nonrecursively referenced variables used
by several related functions as part of an encapsulation is to put those
variables (as globals) and fuctions in a file of their own, and make
everything static (aside from the external interface). This gives the
exact same underlying semantics that you would get from doing the
equivalent in Modula 2, except that in M2, you don't know whether a
display will be used or not (depends on optimization abilities of the
compiler).

>        So far I have found nothing I could do in C that I could not do in
>M2.  To me this is the test of a Language.

Then you've already lost big time, since by that measure you would be
better off using a really high level language instead of either C or
Modula 2.

By the way, my favorite fix for language deficiencies that *really*
get in the way of a project is to write a tiny language that handles
the issue at hand. This can be as trivial as a utility which, when
it's (statically initialized) data structures are edited, recompiled,
and run, produces the desired C data and functions to be included
with the actual program. (This is so easy to do, and can make such a huge
difference in convenience, that I'd say that it's a real must.)

Or for large projects, it can be as complicated as setting up a small
but full fledged language using yacc & lex (bison & flex), some symbol
table routines, and a few pages of C code. There was a discussion about
the merits of this approach in Programming Pearls (CACM) some years ago.

Digressing a bit further, people commonly create scripts/programs/makefiles
that write makefiles which are then executed. For huge projects, three
level indirection is pretty common: makefiles that create makefiles that
create makefiles which finally create a program. Or at my last job,
C programs that created C programs that created C source that was included
as part of a compiler.

The net effect is to stretch current (low) state of the commercially-available
art software development technology by creating software that expertly
assists you in building more software. Current trends aim toward formalizing
and directly supporting this process, which makes far more difference
than which language you're using in the first place.
	Doug
-- 
Doug Merritt		{pyramid,apple}!xdos!doug
Member, Crusaders for a Better Tomorrow		Professional Wildeyed Visionary