Wolfgang Jeltsch wrote:
> Am Montag, 20. März 2006 17:09 schrieb Wolfgang Lux:
>> [...]
>
>> There is a more important reason for using two different
>> primitives for equality and ordering: For some types it is
>> possible to check equality, but they do not have a natural
>> ordering. For instance, MCC supports equality tests for
>> partial applications (which seems natural given that they
>> can be used in equality and disequality constraints), file
>> handles, and also mutable references in the IO monad. However,
>> compare will report an error at runtime when applied to
>> arguments of these kinds.
>
> Brrr, runtime errors! Seems like Curry badly needs type classes. :-)
Brrrr, also.
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.
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.) 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? I don't
see why. In contrast, I was asked only a few days ago, how it might be
possible to have an arbitrary ordering on IORefs (in order to avoid
deadlocks in distributed access to them).
Greetings
Bernd
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Mi Mär 22 2006 - 13:09:16 CET