Wolfgang Lux wrote:
> Nope. ($!!) is of no use when implementing (=:=).
Funny thing to say. I implemented (=:=) exactly by use of that operator.
> Note that (=:=) has to traverse the structure of its arguments anyway
> regardless of whether the arguments are already in normal form or not.
This is only partly true. The main exception is the one you use at
toplevel. As you well know, if one of the arguments is a free variable,
you only have to make sure that the other one is in normal form.
Otherwise, at least in some implementations, "using x=:=goal in order to
evaluate a goal" would be hopelessly inefficient. That is exactly where
(=:=) can make use of a primitive computing the normal form.
>> 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?
As the discussion was partly about typeclasses, I would not say that it
is so sure that (=:=) computes a normal form, if it was a user defined
instance. But don't get me wrong here, I am not that keen on introducing
a new primitive here. I just think that it is not a valid argument that
we need to have equality on functions just because ($!!) could not be
defined. All I wanted to say that IF you do not have such an equality on
everything then you need normal forms as primitive.
>> 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?
I was a bit imprecise here. By "to show the result" I did not mean
"apply the standard show function to the result".
> 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.
Yes, I agree with this. Having pattern matching on partial applications
seems to be along the same line of thought. I got the impression that
showing, reading, comparing, unifying and matching on functions all
belongs to the same base topic.
Greetings
Bernd
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Fr Mär 24 2006 - 10:48:29 CET