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
functions.
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.
Regards,
Frank
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
>regardless
>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.
>
>Regards
>Wolfgang
>
>
>_______________________________________________
>curry mailing list
>curry_at_lists.RWTH-Aachen.DE
>http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
>
>
_______________________________________________
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