a thread on the c programming language

I might as well reply. :)

Yes, the difference between = and == is a PITA. I agree that any new language should probably have a less typo-prone syntax. However, C is not the only language with problems like this. VHDL uses the <= operator to either assign a value or to represent LTE, depending on context. The syntax you proposed, <-, would need similar context checking to differentiate it from a comparison to a negative number. Similarly, replacing { } with [ ] would need further special case checking. I think some of the most intuitive yet flexible syntax is in MOO coding.

Regarding memory leaks: check out Debauch and memleak(which Debauch is based on). You don't need to buy a library when free ones exist. :)

As is obvious from my diary entry, the issue of keystroke efficiency interests me. If it is really an issue to the programmer, I think a language-specific keyboard layout would be beneficial. Perhaps move { and } to an unshifted key, put 'z' and 'x' somewhere out of the way, bring the () keys out of exile... I don't know if any of those would be worthwhile, but they might be. The tools exist for making keyboard layouts; there's no reason to write a new language to save a few keystrokes.
constructive comments: One thing that I would love to see in ANSI C is deep breaks; i.e. breing able to break out of multiple nested loops with one command. Hmm, the syntax break (n); comes to mind, where n is the number of loops to break out of. As well, yes, variable length arrays would be nice.

How many keystrokes to type the code in is much, much less significant than how comprehensible the code is, because any code that matters is going to be read, by humans, far more often than it is written. Arguing about == vs = is pointless; there are millions of people who know enough C to immediately know the difference, while any new syntax you invent, however clear, will have to be learned.

What is more important is a related notion of efficiency: write things once. Ideally, each design decision is reflected in only one place in the code. When this can be achieved, all kinds of good things follow; most importantly that this one place in the code can be changed if needed, revising the design decision, and the code still works. This is the very basic concept of information hiding, which is part of, but which predates, object-oriented programming. Information hiding is important enough, for any software project that you expect to evolve, even to sacrifice some efficiency for. And all software that isn't such crap that you toss it immediately will evolve.

Good C programmers can achieve this property in their code, but it's easier in C++. But some of the worst C++ code I've seen has been produced by people motivated by keystroke efficiency: they overload operators in unnatural ways so they don't have to type as much, and no one can understand their program. Both C and C++ are rich enough languages to allow for elegant or for horrible programming. A new general-purpose programming language isn't going to make people suddenly write only good code.

Can't resist replying so here goes...

I like C and I like it a lot. But I think introducing new features on top of it is probably stretching it too far. Why? because C abstracts the machine and the instruction set and that's about all the nice features one will get from it: an escape from assembly. People who are used to code in assembly and are aware of the runtime can easily relate to C because it provides the abstraction. Like the runtime stack which maps the calling convention of procedures nicely. Parameters are pushed and popped on the local stack. Also, code blocks provide lexical scope like:

{
   int x;
   x = 1;
   {
     int x;
     x = 2;
   }
   {
     int x;
     x = 3;
   }
}

mobius: deep breaks are already in ANSI C.

for ()
{
    for ()
    {
        if ()
            goto DEEP;
    }
}
;
DEEP:

You have many interesting ideas here :) But Isaac Newton got it right when he said, "If I have seen further, it is because I have stood on the backs of giants".

Thing is, at Newton's time, those "giants" were heretics :) There are many interesting ideas in programming language design that people look over because they come from heretical languages.

A "nice" version of C already exists. It's called Ada :) Ada has many of the features of C, but is vastly cleaned up (using some of the suggestions you have here), but has a slightly more verbose syntax. (OK, who am I fooling? The syntax is *much* more verbose.)

But syntax isn't semantics. I wonder how well Ada would have fared if it had a more C-like syntax? It was around by '95, perhaps half of the lustre of Java would be gone...

Some other interesting languages to look at are CWEB, Haskell and Python.

CWEB and Haskell because they use an often-ignored but very useful idea called "literate programming". The key to literate programming, invented by CS great Donald Knuth, is that English is easier to read than code. By letting the programming language take this to its natural conclusion, you get much better programs.

Haskell and Python because they take your idea of keystroke efficiency to their natural conclusion: the "{" and "}" are there for the compiler, not the programmer. Usually indentation is there for the programmer (but not the compiler). As it turns out, it's just as easy for compiler writers to look at the indentation rather than the braces. More keystroke efficient, and fewer bugs as it turns out. (You can miss a brace, but it's dead obvious if you miss a tab).

mobius: The RenderMan shading language has deep breaks (and deep continues) pretty much as you have described them. For relatively small pieces of code such as shaders (they almost never get above 1000 lines or so), it works well enough, but for something like C it could be a major maintenance headache when the loop gets restructured. You really want named break/continue targets (e.g. those of Perl) so you can say "break OUTERLOOP" instead of "break 3".

Let's change topics and consider Perl for a moment. What makes it so ridiculously popular? There are a lot of factors at work here, but what is something that Perl has, that no one else has?

CPAN! What other language can boast a repository of code as large and as diverse as cpan? What's even better is that almost all the modules can be installed with the following sequence:

perl Makefile.PL
make
make test
make install

Let's review. cpan.org provides:

• a large repository of perl modules
• that voluntarily adhere to a standardized build and test framework
• and it's predominantly Free

Cooperation was never this easy, before. People are working together without even knowing it. It's beautiful. The sad thing is.....

No one else is doing this. No one. I'm surprised Python hasn't copied this aspect of Perl. I'm even more surprised that Ruby doesn't have something like cpan set up, yet. It would benefit them so much.

Every once in a while, a discussion pops up about how C could be improved, and the same kinds of suggestions as made here are repeated -- little syntax issues or the dangers of pointers, for example. These are certainly legitimate concerns, but I feel they miss the bigger picture.

I think that if you search a bit, you will find that the kinds of problems the article poses have already been solved in some form or another in languages that exist right now. Has it helped? Maybe a little, but a language does not live by its technical merits alone. A language must also exist within the context of a culture. If a language try's to foster a healthy culture, a community will begin to form around it. The community strengthens the language which then strengthens the community which strengthens the language ... and it doesn't stop.

[jsb]

:= =

is such a big improvement over

= == .

In both cases one operator is used for assignment, and one for comparison, with the two having a symbol in common and one being twice as large as the other. I think that if one fails to distinguish = and == in C, one might similarly confound Pascal's operators. One just needs to pay attention, if not during coding then during compilation when the machine will warn you if it sees something suspect.

But focusing on the characters is barking up the wrong tree. My opinion, based in part on experience, is that mistakes are usually not related to our operators looking too similar. It is because assignment and equality are closely related concepts: after an assignment, the corresponding equality holds true. One operator makes it true, the other tests that truth. I think it would be possible to confuse them on occasion even if they were as different as # and ^^.

Namespaces. This is probably not a bad idea. However, I disagree with ModernRonin again in that there would have to be some kind of escape hatch or "import" mechanism, so that you could refer to something in another file/package without qualifying the name. Otherwise you get silly redundancies like math.cosine(), which would also cancel out that Keystroke Efficiency goal. :-)

Moreover, a module should be able to import names because its task may have a certain focus. A geometry module will likely be doing a lot of math calls, and I think it's better to just specify this with an import command than to repeat some prefix again and again.

Pointers. The suggestion is to turn pointers into the equivalent of C++ "references" where you must initialize them, and cannot assign them thereafter. (I will for now ignore that this can make the distinction between assigning a reference and copying an object very vague, an issue that was brought up in the example about assigning one struct to another where one of them owned storage.)

This will prevent wild pointers, but it will also make prevent many valid uses of them. There are many instances in which you will want to reassign the referent of a pointer/reference variable. The implementation of almost any data structure would qualify as such a situation, unless you are crazy about implementing linked lists the way they used to do them in Fortran with parallel arrays.

This is less important for languages with built-in data structures, of course. And if you're designing a language such as this, then leaving out pointers is no problem as long as you provide library or language support for the things people would otherwise be using them for.

Garbage Collection. I wish this argument were cast like this a bit less often. There are situations in which the disadvantages of manual memory management are acceptable and those of GC are not, and there are situations in which the disadvantages of GC are acceptable and those of manual management are not. I do not see how progress demands one or the other. Both are useful at times.

A few quick notes, which of course not say something about your shoe-size IQ, unless you have really large feet:

Memory management

A GC *may* sometimes be a nice thing, but it isn't suitable for everything. Not only that it slows down applications, it brings some other problem: You are intruducing the GC to help beginners, which is the same what sun did with java. The result simply is that beginners have no feeling about memory size and do new's like hell in their programs.

Keystroke Efficiency

On a german keyboard, []{} are on Right-Alt-7 to Right-Alt-0. Swapping those doesn't give me anything, it's still a finger-bone-breaking issue. :)

Your language proposal isn't even a usable language. Consider these overloaded functions...

   int func.int,int;
  
   int func.int;

... and this statement ...

  a = func.func.3,4;

... now which function is called for the inner and which for the outer? Both "func( func(3), 4 )" and "func( func(3,4) )" could it be.

jaz: It may, of course, be that I've only seen such "toy GC's" so far, but my impression is that removing the need for manual deallocation immediatly leads to bloated programs which are both slow and memory-suckers. (Lisp, for example, is something I never touched).

I also agree that there are languages which couldn't exist without a GC, but in this thread we were talking about C (or however the proposed language dialect would be called)

To be honest, I have never seen a program where manual memory managment was nearly impossible to implement (Including a bunch of really complex optimization programs). In all cases, it turned out that some kind of "ownership" mentality did it all right, that is, every allocated memory structure is owned by some other structure, function, or module, and is deallocated whenever the owner's lifetime is over (function exit, structure deallocation, or module's end). So far, no program I ever wrote or saw broke this idea.

But, still, I'd gladly bow for your greater wisdom. Perhaps my horizon is just too close. Who knows?

ModernRonin is right, C and C++ have some features that are powerful yet dangerous and tough to use right. It's probably best to think of C as "portable assembly language." I say this as a longtime C hacker. :^)

But it sounds to me like this "improved C/C++" is really Java, minus the kitchen-sink class libraries. Because fundamentally, Java is just pointer-safe C/C++ with garbage collection and some cleaned-up syntax. Oh, and a specified abstract virtual machine to run in. [donning asbestos suit now ...]

My opinion: C is a great language as-is for building operating systems, embedded systems, and libraries and components. And, if you know C well, you will be OK using it to attack other problems as well.

But other problem spaces are also served quite well by "safer" languages, and we have those in abundance: Perl, Python, Tcl, Scheme/Guile, etc. Oh, and there's this Java thing that fits in somewhere as well.

I guess I'm not enough of a computer language nerd to want to go tweaking C. Like many other things, it's very easy to write a bad computer language. If C/C++ is not a good fit, pick a language that fits the problem better.

Regardless of Political and Free Software/Open Source arguments. Java is awesome. I that would suggest everyone with an interest in language design read "The Java Language Specification" by James Gosling, Bill Joy and Guy Steele. They did an awesome job.

The point is that SUNs implementation of all this has been pathetic. Java is Closed/Proprietary and they won't even send it to a standards committee! That said the GNU community will have an awesome Java compiler (GNU Java Compiler) in GCC 3.0. This should be largely JDK 1.1.8 compliant and ready for prime time.

The issues you bring up WRT Java and C++ are something that I haven't had to think about for a number of years now :).

....

Assignment/comparison confusion is rampant in C and C++. However, gcc (and I suspect other compilers) can catch this condition, and at least issue a warning to you, so you know to take a closer look at your code. Substituting ":" for "=" will just hurt the human parsers. You can recude your foul rate in this area by taking the habit of putting a constant for comparison first, e.g. "if ( 0 = x ) { ... }". The compiler won't let you get away with that assignment. Granted, this doesn't work for variables, but healthy usage of assertions will point these problems out early on.

Pointers are extremely confusing in C and C++. Which is why I believe that everyone should code a generic doubly linked list implementation, just to make sure they do understand the concept. The majority of my programming errors have been due to missing my target by one level of dereferencing. This is just a hazard of the C/C++ programming language, and is learned by experience. C++ also offers references as a language feature, but if you don't understand pointers, you're not likely to understand when references are better suited to your task.

Memory management is the reigning champion of C/C++ programming mistakes. I personally believe that most of this is due to a woefully inadequate string implementation in C, that forces the programmer to check everything twice. C++ at least gives you a reasonable string class so you don't have to micromanage the memory allocations for each string operation. There are also garbage collectors for C and C++, as well as free memory integrity checking libraries (dmalloc, electricfence, etc.).

Keystroke efficiency is a red herring. If you are spending most of your time at the keyboard, you're not spending enough time doing design work. Not to mention that you'll spend ten times the amount of time trying to figure out why a piece of code isn't doing what you want it to. A decent choice of symbols makes it much easier for the human parser to do its thing properly. Code a few hours a day for a year, and whether or not you have to hit the shift key won't make a big difference when reaching for those funny symbols.

All in all, it sounds like you might want to try taking Java, Python, or Tcl for a spin. If you take the time to learn what C++ has to offer, you will realize that the biggest flaws in the language are there for compatibility with existing C code. If those are your biggest complaints about the language, you'll probably be happier programming in one of those other languages.

Unfortunately, that says more about your experience than about garbage collection in general.

Here is something that is useful in C, but very hard to do without proper GC: linked lists with shared tails. For example,

  node* prepend (node *p)
  {
   node* n = make_node ();
   n->next = p;


    return n;
  }

   ...

   verylonglist = ...
  l1 = prepend (verylonglist);
  l2 = prepend (verylonglist);

l1 and l2 share their tail, and the tail may only be freed if both l1 and l2 go out of scope. This is hard to tell when that happens, especially if the lifetimes of l1 and l2 are different.

Constructions like these abound in functional languages (where values are generally read-only, and consing onto list tails is a very natural thing to do), but they do have an application in C: sharing tails can save a lot of memory in the right circumstances.

Anyways, if you think GC is Bad Idea, I urge you to read The GC FAQ and Paul R. Wilsons survey of uniprocessor GC techniques (which debunks many common myths about GC)

...and that's pretty much all I have to say :)...

I shouldn't be so blunt, but I've worked with so many languages and so many systems. Each one of them have had their fatal flaws. Except in rare cases, each abstraction system has difficulties representing every practical task. The key is to let your mind discover the strengths and weaknesses of the system you are using, and see how to adapt those to the task at hand.

two of modernronin's points are related to a more general idea, one that the butt-ugly fish book discusses:

One problem is that C is so terse. Just adding, changing, or omitting a single character often gives you a program that is still valid but does something entirely different. Worse than that, many symbols are "overloaded" -- given different meanings when used in different contexts. Even some keywords are overloaded with several meanings, which is the main reason that C scope rules are not intuitively clear to programmers. Table 2-1 shows how similar C symbols have multiple different meanings.

Table 2-1, Symbol Overloading in C

Symbol     Meaning

 static     Inside a function, retains its value between calls
           At the function level, visible only in this file

 extern     Applied to a funciton definition, has global scope
           (and is redundant)
           Applied to a variable, defined elsewhere

 void       As the return type of a function, doesn't return a value
           In a pointer declaration, the type of a generic pointer
           In a parameter list, takes no parameters

 *          The multiplication operator
           Applied to a pointer, indirection
           In a declaration, a pointer

 &          Bitwise AND operator
           Address-of operator

 =          Assignment operator

 =          Assignment operator

 ==         Comparison operator

 <=         Less-than or equal-to operator

 <<=        Compound shift-left assignment operator

 <          Less-than operator
<<         Left delimiter in #include directive

 ( )        Enclose formal parameters in a function definition
           Make a function call
           Provide expression precedence
           Convert (cast) a value to a different type
           Define a macro with arguments
           Make a macro call with arguments
           Enclose the operand of the sizeof operator when it is a
           typename

[ ... ]

The more work you make one symbol do, the harder it is for the compiler to detect anomalies in your use of it. It's not just the kind of people who sing along with the Tiki birds at Disneyland who have trouble here. C does seem to be a little further out on the ragged edge of token ambiguity than most other languages.

With the abundance of symbols we can have in our systems today, there is no good reason why some of this should not be remedied.

C is a language, which tries to be something very specific -- portable assembler. It is quite good at that. I will even go further, and say it is wonderful at that. Not that there are no competitors (FORTH comes to mind), but it pretty much dominates the market.

If you want to use a language which gives you better mechanisms, do not program directly to the CPU. Use Java, use Common Lisp or (my personal favourite) use Python.

Of course, the big advantage of Python is that it is close enough to C to make extending in C a very easy thing so you can do what all of humanity has been doing for ages: OPTIMIZE IN ASSEMBLER, code in high level languages.

A good workman invests in and takes responsibility for his tools. If all you have is a cigarette lighter it doesn't matter how good you are at plumbing; you still shouldn't be soldering pipes for central heating systems with it.

I don't agree with the author of your quote. Normally C gets criticized for its set of operator symbols being too large; it's even weirder to think we might be better off using Unicode operators, so that there will be no ambiguity about symbols.

C does use the same ASCII characters for more than one purpose. But I do not think we automatically need more symbols just because we have encodings for them. (I will ignore the obvious issue that keyboards don't have easy ways to type Unicode characters.)

Where he may be right are static, extern, and the & operator. Another symbol could have been used for taking the address of an object that did not lend itself to easy confusion with logical AND (which does deserve the ampersand in the absence of a key for the real mathematical symbol.)

Dollar sign would have been fine. I don't know what programmer or compiler will really confuse this one binary operator with the other unary one, but I will grant the point that it could be more clear.

We should not allow these irregularities to mask the fact that for the most part, C's set of operators and keywords has a strong internal logic and regularity. (If you want to discuss the precedence and associativity table that is another thing.)

The bit about the less-than and greater-than signs is rather wacky. Programmers don't confuse preprocessor directives with logic expressions. The compiler never sees #include lines so it is not working harder there either.

Compound operators. The point of having these is that they are regular in structure and can be built without having to memorize all of them. You will occasionally run into old compilers that do them backwards, but in any case the similarity of the compound assignment operators to their counterparts is an aid to clarity and not a hindrance.

The discussion of the void keyword seems to ignore the logic behind C's declaration syntax, and its correspondence with that of expressions. Declaration mirrors use, and understanding this shows you why C's uses of the void keyword are completely consistent.

• Void means "nothing." As a return type this means the function returns "nothing."
• As a parameter list it means that the function accepts "nothing" as a parameter.
• A declaration like void *p; makes total sense if you realize that declaration is supposed to mimic expressions. What is the type of (*p)? You can't dereference generic pointers, so the answer is "nothing". The right half is "of the type" left-half.

I work as a CS tutor at university, and this reasoning always helps them figure out one of C's most sticky syntax points: function pointers. Take int *(*fp)(void);. What is the type of the expression *(*fp)();? This calls the function and indirects the pointer returned by that function. Yielding int, the left- half of the declaration. ANSI C provides a bit of syntactic sugar with the usage of function pointers (you can just do fp()) but otherwise it is completely consistent.

To sum up... the quoted text shows that C makes many symbols do double-duty, but fails to establish its being a problem in most of those cases. IMO it's better for many things to have an internal logic whose grokking has benefits than for everything to be intuitively obvious but irregular.

well, i didn't really feel like typing in much more than i did. in the end, though, it's a matter of judgement, and you're perfectly entitled to that assessment.

this section, called "the $20 million bug", is from the introduction of the same book (i.e., not in the same part of the book as the other excerpt i posted).

In Spring 1993, in the Operating System development group at SunSoft, we had a "priority one" bug report come in describing a problem in the asynchronous I/O library. The bug was holding up the sale of $20 million worth of hardware to a customer who specifically needed the library functionality, so we were extremely motivated to find it. After some intensive debugging sessions, the problem was finally traced to a statement that read:

x==2;

It was a typo for what was intended to be an assignment statement. The programmer's finger had bounced on the "equals" key, accidentally pressing it twice instead of once. The statement as written compared x to 2, generated true or false, and discarded the result.

C is enough of an expression language that the compiler did not complain about a statement which evaluated an expression, had no side-effects, and simply threw away the result. We didn't know whether to bless our good fortune at locating the problem, or cry with frustration at such a common typing error causing such an expensive problem. Some versions of the lint program would have detected this problem, but it's all too easy to avoid the automatic use of this essential tool.

i think i've pretty much exhausted my quota of fair use. after this, if you're interested in hearing what van der linden has to say, please read the book.

The idea that a declaration should look like a use seems to be original with C, and it hasn't been adopted by any other languages. Then again, it may be that declaration looks like use was not quite the splendid idea that it seemed at the time. What's so great about two different things being made to look the same? The folks from Bell Laboratories acknowledge the criticism, but defend this decision to the death even today. A better idea would have been to declare a pointer as

int &p;

which at least suggests that p is the address of an integer. This syntax has now been claimed by C++ to indicate a call by reference parameter.

The biggest problem is that you can no longer read a declaration from left to right, as people find most natural. The situation got worse with the introduction of the volatile and const keywords with ANSI C; since these keywords appear only in a declaration (not in a use), there are now fewer cases in which the use of a variable mimics its declaration. Anything that is styled like a declaration but doesn't have an identifier (such as a formal parameter declaration or a cast) looks funny. If you want to cast something to the type of pointer-to-array, you have to express the cast as:

char (*j)[20]; /* j is a pointer to an array of 20 char */
j = (char (*)[20]) malloc( 20 );

If you leave out the apparently redundant parentheses around the asterisk, it becomes invalid.

A declaration involving a pointer and a const has several possible orderings:

const int * grape;
int const * grape;
int * const grape_jelly;

The last of these cases makes the pointer read-only, whereas the other two make the object that it points at read-only; and of course, both the object and what it points at might be constant. Either of the following equivalent declarations will accomplish this:

const int * const grape_jam;
int const * const grape_jam;

The ANSI standard implicitly acknowledges other problems when it mentions that the typedef specifier is called a "storage-class specifier" for syntactic convenience only. [...]

Considering the problems discussed, I'd recommend taking a look at Pliant (http://helio.pliant.cx/). It solves the pointer/referense trouble by having explicit reference types (in C, pointers are not actually data types but rather just crude memory segment locators). These pointers also solves the memory management trouble like so: reference counting. When something gets pointed to, its reference count goes up. When a pointer goes out of scope (or is explicitly changed to point elsewhere or to NULL), the reference count of the something goes down. When count goes zero the something is deallocated by the runtime system. Anything pointed to by (members of) the deallocated something will have their reference counters decreased as well.

Reference counting is much faster and much more precise than GC. This is so since the something can be deallocated at once when no one points to it anymore. GC is inherently bad at this and if your something is a thread, then it could still get a lot of runtime and produce endless nonsense before the GC gets to run and kill it. Reference counting is also faster than GC since the runtime system does not have to search for stuff to deallocate; The reference counter knows which memory segment it is coupled with.

Pliant also have a very clean syntax with quite few meta-shift-bouble-bucky charcters.

In fact, if I could make one single change to the C ANSI standard it would be to bring over the reference/pointer system from Pliant. The */& shit would stay but could then be reserved for strange hardware driver stuff where it may actually make sense.

harebra / klasa

Reference counting is rarely used since it has a major flaw. Consider this:

struct thing
{
  struct thing * anotherthing;
  char muchmemory[much];
}

 ... function(...)
{
  struct thing th;

   th.anotherthing = &th;
}

After function() returned, it's thing has a reference count of 1, since the pointer in the thing still points to itself. That will never be fixed (since the application lost access to the structure), and the structure will exist forever.

Hi ali

In this case it seems that use of your referense -- after the function returns -- should generate a bus error or a segmentation fault. When allocating something so that it becomes local to a function in this way, the memory should be reserved on the stack by the language's runtime system. When th goes out of scope (on return), the memory stack should roll back and deallocate the struct. Returning a pointer to stack allocated material like this should generate a compile time error in any sane compiler (with the possible exception of C maybe).

Even if you had allocated th on the heap you should be ok in case of Pliant, since it has some means of detecting circular referenses. Check the docs.

harebra / klasa

I wanted to post a couple of points about C and C++ not

having garbage collection:

• It's the programmer's responsibility to use an

  appropriate resource control mechanism.

• Garbage collection is only the 'magic' solution for

  memory. What about other resources? Is the runtime system

  smart enough to run the GC when you're out of filehandles?

  How about when you're out of foos?

• Do you really want garbage collection to be an integral

  feature of a language you used to right an OS?

In my opinion, a language that gives you choice and

flexibility in resource control techniques is much better

and a big win over a language that doesn't.

In my StreamModule system, I use reference counting for a

data structure (the structure representing a sequence of

bytes) that can only be a DAG by the rules under which it is

built. This is exactly the appropriate technique. The

reference counting overhead is incurred in a very

predictable and controllable manner.

I even have a small infrastructure (smart pointer classes

and a mixin class that has the counter) built up to make it

easy for a certain data structure to participate in

reference counting where appropriate. In fact, in the

combining list tails problem that someone mentions is a

perfect candidate for using this infrastructure.

If ever I wanted cycle-resistant mark & sweep style

garbage collection, I could find it or implement it and use

it for exactly those data structures it was appropriate for.

With a little discipline in how you use pointers and a

little programmer prodded compiler assistance, you can

operate a non-conservative mark & sweep collector in an

environment that doesn't enforce one from the top down.

In Python, Perl, and other such 'scripting' languages,

garbage collection is the right answer. In Java, it's a

descision I strongly question. In C, C++, Ada, FORTRAN, and

other such 'systems' languages, it's the wrong answer.

I cut and pasted from a 'view source' window, and it stuck in extra <p> tags at all the line breaks.