                 Misc notes on the Presto implementation


- Define and apply a rational policy on include files.  For modularity,
  we'd like a file foo.h to include all the .h files on which it depends.
  But then can we have precompiled headers?

- Similarly for libs.

- Let changeo use the spritelib in a more C++ native way.  Depends on an
  include file policy.

- Add printing support to our types where possible.

- Let's use case-rich file names in the makefiles and #include statements,
  e.g., "Point2B.obj" and "Point2B.h". Maybe we'll be able to fix the
  slm'd file names later.

- Unify "Time" vs "SpriteTime"

- Make methods like _spritify, _at, _do be private, but with spritify, at,
  and do as "friends".

- Precompiled headers

- Capture dependencies on .h files in makefile

- The XXXObj class declarations must go into .h files, for extensibility.

- Make behavior arithmetic be generic, so we can use it directly on
  colors, etc.  Try:

    template<class in1, class in2, class out>
    Behavior<c> operator-(Behavior<a> b1, Behavior<b> b2) {
      return lift2b<in1,in2,out>(sub, b1, b2);
    }

  Support with a macro.  Why not in1=in2=out?  Because (a)
  point-point=vector, and (b) scalar*vector=vector

- Should we generalize sin, cos, etc in the same way?  Seems appropriate,
  since they may be overloaded on many static types, not just reals.
  Hmm..., then the RealB module is not really about reals.

- Generalize from behaviors (Time->a) to "maps" (a->b), and support
  syntactic images (Point2->MaybeColor), and surfaces (Point2->Point3).
  One very annoying problem (at least as of 7ish years ago): C++ doesn't
  support template typedefs.  (And John T and I just tried with gcc.)

  I think the liftings should not be specialized to time, but rather left
  to be entirely general, so we can use them for image formation, etc.
  What about "time"?  Generalize it.  

- Constant folding for behaviors, and for ActionB.

- Learn and use STL.  In particular, check out the <functional> stuff,
  and maybe use it instead of Behavior or Map.

- Separate SpriteLib into inc and src

- What flavor of "assert" should we use?

- Precompiled headers would speed up compilation.

- Reconcile RGBcolor vs point2XY.

- Reconcile question of public members for concrete classes.  See
  monochrom "Update" ImageB.cpp.

- Defining constants like red and origin at the static level potentially
  causes more lifting than necessary.  (But it's more general, since it
  can be used for both static and behavioral.)  Ditto for numeric
  literals, though I don't know what to do in that case.

- Move color and rectangle types into spritelib and provide higher level
  constructors and update methods as suggested in ImageB.cpp

- Instrument spritelib so that it can tell us if it is using hw surfaces

- We now allow both the MFC ASSERT and DA Assert capitolization; eventualy we 
  should standardize on one!
