🚀 go-pugleaf

In article <268@hitech.ht.oz> clyde@hitech.ht.oz (Clyde Smith-Stubbs) writes:
>Implementation of displays in C is not difficult, and properly done need
>not add much overhead.

The overhead that it *does* add is invisible, which is what some people
like about it, but is also why it doesn't fit C.

>Indeed, since it is something that adds no overhead
>unless you use it (global functions don't use the display) it fits quite
>well with that amorphous "Spirit of C".

Sorry to say you've gone off the deep end here. That argument could
be used to justify *anything*. Just add a new type called SEXPR which
supports garbage collected dynamic lists. After all, if you don't use
it, it doesn't cost anything at all!!!

Handy though such features may be, they are not in alignment with
C's philosophy.

>There are certain recursive
>tasks that nested functions can be used to implement in a much more
>transparent fashion than doing it by hand (I know, I have had to write
>code that effectively maintains a manual display one level deep).

Yes, and there are some things that Lisp does much more transparently
than C. Again, this is not an argument for adding features to C, it
is an argument for using a different language. Or creating (yet another)
new language, like *((fancy *) C)++.

Once again, C is *supposed* to be a "high level" (not very) systems
programming language that exposes *simple* abstractions of the (*slightly*
idealized) hardware to *direct* manipulation by the programmer, who
is expected to be grateful that there aren't thousands of hidden machine
cycles executed every time he does something that looks simple.

Many languages, including Algol, PL/1, Lisp, Snobol and even Cobol have
at least *some* transparent, expensive conveniences that would be handy
at times, and they all predate C by many years. C is not what it is because
its designers were ignorant of such mechanisms; they left them out *on purpose*.

You don't have to like C or its philosophy, but equally don't expect it
to be something that it's not.
	Doug

P.S. I think Mike Meyer was the first to point out that Displays are
a poor substitute for first class data abstraction features, anyway,
so why worry about second best? Start arguing about adding objects,
classes, inheritence, etc, and people will say "use C++/Objective C/Smalltalk"
and then you'll be on the right track.
-- 
Doug Merritt		{pyramid,apple}!xdos!doug
Member, Crusaders for a Better Tomorrow		Professional Wildeyed Visionary