Bernd Brassel wrote:
> Somehow this argument does not convince me. There are a lot of types,
> which have no "natural order", even if they have a representation as
> user defined data types. And because we have no type classes, we
> impose
> a conventional order on them. The same would be possible for
> functions.
Ok. If you can tell me what the result of
id `compare` const 0
is (and how I'd generalize that to arbitrary functions), I'll be happy
to implement that.
> And by the way, IF we had type classes it might still be debatable
> whether functions should be of class Eq (and also of class
> Unifiable, or
> whatever we would call those usable in constraints.)
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.
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]
> Neither way, I do
> not see why a "runtime error" is in any sense better, neither "more
> natural" nor "making more sense". And does the equality on IORefs or
> file handles make more sense than an arbitrary ordering does?
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.
Regards
Wolfgang
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Mi Mär 22 2006 - 18:34:46 CET