Expected behavior of "deriving Ord"?

[Conal Elliott]

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 at 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.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080331/1597cb47/attachment.htm