Bernd Brassel wrote:
> Wolfgang Lux wrote:
>
>> 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.
>
> How about just computing the normal form of goal?
That is exactly what the equality constraint does. After all (=:=) is
based on strict equality so it necessarily must evaluate its arguments
to normal form. So why introduce another means to compute a normal form?
In fact, using x=:=goal in order to evaluate a goal (unless it has
type IO a) looks just like the equivalent of the implicit print
application
performed by a Haskell interpreter when you enter an expression that
does
not have type IO a.
> Isn't that done when
> trying to show that result?
No. In contrast to a Haskell interpreter, a Curry interpreter cannot
evaluate a goal lazily while it is printing the result. Instead, it
must evaluate the goal to normal form before it can start printing
the result. Otherwise, you'd get into troubles with unbound variables
and concurrency. And note that you cannot use show for printing the
result because show (necessarily) is a rigid function. Otherwise,
what would be the result of let x,y free in x=:=show y & y=:=1?
> And by the way, showing functions is just
> part of the same problem. (Functions are also not in calss Show in
> Haskell for good reasons, I guess.)
>
>> 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]
>
> Yes, that is only because of the not so fortunate definition of $!!.
I don't think it is unfortunate. I rather think it is the most
reasonable
definition of this operator.
> As far as I understood it, Michael meant that to be rather
> documentary. I
> think it would be more natural to have it as a primitive, as (=:=) has
> to use something like such a primitive anyway.
Nope. ($!!) is of no use when implementing (=:=). Note that (=:=) has to
traverse the structure of its arguments anyway regardless of whether the
arguments are already in normal form or not. So you can as well evaluate
the arguments just on the fly as for other user defined functions.
>> 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.
>
> You could still have compare either yield EQ or a run-time error, if
> that is so appropreate.
That would be possible. But even then there remains a difference between
a primitive (==) and a function (==) defined in terms of compare:
do
r1 <- newIORef 0
r2 <- newIORef 1
return (r1 == r2)
With a primitive (==) this will return False, whereas (==) based on
compare would fail at runtime.
> I do not see that having compare always failing
> could be any better. Why does this make more sense? Of course if you
> would like to have a total compare for such things, you would have to
> number each object upon creation, which is not hard to do but has
> only a
> questionable advantage.
Yes. This is exactly the kind of thing I want to avoid and why
I'm arguing that (==) should not be defined in terms of compare.
Nevertheless, since we are talking about extensions to the Curry
language as far as the report is concerned, I will not object if
Michael decides otherwise and defines (==) in terms of compare in
the report because it does not seem to make a difference in that
context. And as long as the language defined in the report does not
include partial patterns in function heads, I won't ask for equality
between functions becoming part of the report.
Regards
Wolfgang
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Do Mär 23 2006 - 21:05:37 CET