- stack and list classes should have operator=() !!!
  * This will be rather messy to implement... as it will require operator=() on
    all the nodes, which in turn may require operator=() on the contained
    objects. This is OK for the e-containers; but the o-containers will then
    have to force contained objects to implement operator=().
- list (perhaps also stack) classes need a cut() operator that allows more
  efficient destructive list copying/attaching. How about something similar to
  Perl's splice?
- revise existing libs to use it (our libs REALLY need non-b0rked exception
  handling; error.h is only good for C)
  - implement error-handling in stack templates!!
    * must use new exception.* classes.
- implement target to build tar.gz archive, with semi-automatic MANIFEST
  generation, etc..
+ implement standardized library error-code passing. This will probably be
  based on the error_d/error_t strategy using error codes that are unified
  with their respective error messages.
+ re-design the interface for the FILE hierarchy. You'll also need to consider
  how to maximize backward compatibility while fixing flaws in the original 
  design.
+ implement iterators for stack templates!
+ look into why *iter++ doesn't compile, in list.h. Possibly due to
  operator++ return type: maybe we shouldn't specify return type??
  ** No, the problem is, operator++() must be overloaded to return the
  derived class object rather than the base class object. This is NOT
  automatically done!
+ implement doubly-linked lists!
X port SPLITSRC. Or perhaps re-implement it, since the existing code is too
  messy.
  * Forget it. It's not that useful anymore... or at least, if you want it,
    you should redesign with a less b0rked design!
X design a set of basic print-formatting operations, such as typesetting
  integers, etc., that respects buffer bounds.
  * Finally the libc people have caught on, and have implemented niceties like
    snprintf() and vsnprintf().
+ re-organize this messy directory!
  + convert to use Cons
  + separate C and C++ libs (too messy otherwise).
X file.h probably needs re-designing... esp. the read/write interface
  (though fread/fwrite seems cumbersome, they have better error behaviour
  when it comes to file size).
  * the file.* hierarchy has been deprecated. Design is obsolete.
X re-design config file module!
  * will need redesign from scratch; old design is obsolete.
X write README file for this dir to describe lib usage. In particular,
  note that alternative implementations of a module can be selected by
  specifying the implementation dir in the #include path, eg.:
	#include <ansic/pfile.h>
	#include <linux/config.h>
  This mechanism has many flaws, though... we should come up with a better
  way of managing selection of alternative implementations!
  * Split up into C/C++ libraries. We'll worry about alternative
    implementations in the future. At any rate, it should be much easier
    under Cons.
X adapt DBUF module code to work with new error-code passing scheme.
  * DBUF is obsolete. Probably should adapt idea into a better design.
X clean up code for buffered file classes (BFILE module). You need to make it
  more secure!
  * the FILE hierarchy is obsolete.
+ incorporate better exception-handling class from atom4/x
  + probably need to clean it up a bit before we put it in here
    + at least need some form of locus field
    + *could* just implement this as class hierarchy and just have the locus
      as a convention rather than an enforced rule.
