The issue is more than just efficiency.  It's vital that these improving values get evaluated as little as possible.  In my use for functional reactivity, they represent the times of future event occurrences. 

Your (<=)-via-min idea might work in some cases, though useful pointer equality can be pretty tricky in the presence of laziness.  It's one thing to use pointer equality in lazy memo functions, where false negatives are okay, but in this case, a false negative (pointer inequality between semantically equal values) would give the wrong answer for min.  Also, the assumption that min returns one of its arguments is questionable.  It's certainly not the case in Warren Burton's implementation of improving values (refs in previous mail).  Instead, min merges the lower bounds from each argument into the result.  Of course min returns a value semantically equal to one of its arguments, but a pointer-equality test would fail, and a semantic equality test would block.

Cheers,  - Conal

On Mon, Mar 31, 2008 at 1:34 AM, Christian Maeder <Christian.Maeder@dfki.de> wrote:
Christian Maeder wrote:
> Conal Elliott wrote:
>> The type argument I ran into trouble with represents a value as a list
>> of increasing lower bounds, ending in the exact value.  min produces
>> lower bounds from lower bounds and so is immediately productive before
>> even knowing which argument is the lesser one.
>
> Is this only a matter of efficiency? Can it be compared with a faster
> equality check that does not need to evaluate terms always, because it
> compares the internal pointers first (and returns True for equal ones)?
>

Because min returns one of its arguments, "<=" could be defined in terms
of "min" and equality.

 a <= b = min a b == a

"==" would cause further evaluations, but if an equality could look up
pointers (to unevaluated thunks) no further evaluation might be
necessary, so that min and <= do basically the same.

> Cheers Christian
>
> P.S. Maybe it is still a good idea to have a separate user defined class
>  Min for your purpose, because then you don't have to hand-write compare
> functions, but then I don't know the nesting of your data types, though
> a generic instance Ord a => Min a may help.
>