On to Hydro

[Mark S. Miller]

Since no one has been able to marshal a good defense of keeping mutable 
collections in the normal-use library, since you've pointed out that even 
the immutable subset of E's current collections violates the principle of 
least authority (in it's "no subtypes that add authority" guise), and since 
Bill's defense of KeyKOS and EROS using the "bad" pattern is OS specific, I 
accept the inevitability of changing the collection classes along the lines 
we're discussing.

Unless anyone has a good objection, the next release of E will continue to 
use the current collection library by default, but will also experimentally 
include the 1.0 version of Hydro, so we can start playing around with it.  
Since Tyler & I both have strong styles, and since these styles are 
different, it'll be interesting seeing what kinds of conflicts we have.  
Here's the first one I saw:


The contract for Comparison states that it provides a total order, but the 
implementation of GreaterDouble (an implementation of Comparison) says:

     /**
      * Compares the values of two <code>Double</code> objects.
      * @return  <code>true</code> if the first <code>Double</code>
      *          has a greater value.
      */
     public static
     boolean compare(Double a, Double b)
     {
         return a.doubleValue() > b.doubleValue();
     }

In Java and IEEE, ">" is not a total ordering on floating point values.  
Rather,

     anything < NaN   yields false

and

     anything > NaN   yields false

This was one of the cases that led me to specify that these operators in E 
provide a partial order.  Another is "<" for strict subset.


         Cheers,
         --MarkM