Changes by: Jason J. Hickey (jyh at cs.caltech.edu)
Date: 2007-05-03 16:10:46 -0700 (Thu, 03 May 2007)
Revision: 10621
Log message:

      Re-naming to match rev 10620.
     
     I've been thinking about the new scheme.  I like the basic idea, but I am
     not sure about it.
     
     The entire reason to use cons-hashing is to improve performance of the
     compare function.  In the original implementation, if the hash is perfect,
     comparisons take time O(1).  We go through great pains to get good hashes. 
     I haven't checked recently, but the original implementation showed 2
     hash collisions (out of about 1e6 comparisons IIRC) for a MetaPRL compile.
     
     The problem with the new implementation is that the normal operation, the
     coarse comparison, now gets a lot of collisions *by definition*.
     
     There is a solution, which is a vertical split, where each fine
     node has the hash-consed coarse node as a component.  Comparisons
     should be based on the coarse node, but the full hash-consing would
     be case-sensitive.
     
     To be more explicit, something like this:
     
        type coarse_dir =
            DirCoarseRoot of Lm_filename_util.root
          | DirCoarseSub of FileCase.t * DirCoarseHash.t
     
        type dir =
            DirRoot of Lm_filename_util.root
          | DirSub  of string * DirHash.t * DirCoarseHash.t