Wolfgang Lux wrote:
> I agree that the point of allowing functions in constraints and
> equalities is debatable. However, without them MCC would be unable
> to evaluate a top-level goal like
> Just id
> since the interactive top-level evaluates a goal by using the
> equality constraint
> x=:=goal
> where x is a fresh variable.
How about just computing the normal form of goal? Isn't that done when
trying to show that result? And by the way, showing functions is just
part of the same problem. (Functions are also not in calss Show in
Haskell for good reasons, I guess.)
> Also note that if equality constraints for functions weren't supported,
> you would be in trouble when evaluating the expression
> length $!! map const [0,1,2,3]
Yes, that is only because of the not so fortunate definition of $!!. As
far as I understood it, Michael meant that to be rather documentary. I
think it would be more natural to have it as a primitive, as (=:=) has
to use something like such a primitive anyway.
> Any Curry implementation I can think of will get equality of IORefs and
> file handles for free (in most implementations this should be physical
> equality of the underlying representation). However, implementing a
> stable(!) ordering for these types requires additional support from the
> implementation.
You could still have compare either yield EQ or a run-time error, if
that is so appropreate. I do not see that having compare always failing
could be any better. Why does this make more sense? Of course if you
would like to have a total compare for such things, you would have to
number each object upon creation, which is not hard to do but has only a
questionable advantage.
Cheers
Bernd
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Do Mär 23 2006 - 14:25:03 CET