Re: Curry Report Vers. 0.8.2

From: Wolfgang Lux <>
Date: Wed, 22 Mar 2006 17:42:22 +0100

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
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


curry mailing list
Received on Mi Mär 22 2006 - 18:34:46 CET

This archive was generated by hypermail 2.3.0 : Do Jun 20 2024 - 07:15:08 CEST