Re: Curry Report Vers. 0.8.2

From: Frank Huch <>
Date: Wed, 22 Mar 2006 18:25:09 +0100

Hi Wolfgang,

I do not like the idea of comparing functions at all. Is there a good
explanation when functions are equivalent? You say const 0 == const 0
yields True. However, these are two different applications and hence
different pointers in the heap. Furthermore, the semantics of pointer
equivalence is quite problemeatic since optimizations as inlining or
common subexpression elimination may change the result of comparing
As a consequence, the only interpretation for (==) on functions would
for me be a comparison of string representations of both functions
(which for sure can be implemented more directly than comparing Strings
in MCC and PAKCS). But, if (==) is defined by comparing String
representations, then I don't see a reason for not defining a standard
ordering on these values, as it is done for other datatypes.

I would prefer to have neither (==) nor (<=) for functions.
But, there is no good reason for having (==) and not having (<=).

Since Curry does not provide type classes, the only possibility to
restrict (==) or (<=) for special types (which I agree is sensible) are
runtime errors.


Wolfgang Lux wrote:
>Bernd Brassel wrote:
>>Thus, why not agree to Sebastians suggestion and express all the
>>primitives, including (==) by compare?
>Because the important difference between (==) and compare remains
>of whether compare is a total function as Michael suggested or
>whether it fails
>at runtime as in the current MCC implementation. For instance,
> const 0 == const 0
>yields True, but
> const 0 `compare` const 0
>either fails at runtime or causes a runtime error.
>curry mailing list

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