Bernd Brassel wrote:
> Wolfgang Lux wrote:
> > Nope. ($!!) is of no use when implementing (=:=).
>
> Funny thing to say. I implemented (=:=) exactly by use of that operator.
I think it would be interesting to see your definition of (=:=)
in terms of ($!!), since (=:=) does not always compute the normal
form of both arguments (e.g., if one argument has no value).
> 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.
Why do you think it is "hopelessly inefficient"? Any conrete
numbers from your implementation? I did this optimization you
mentioned and it was an improvement of around 30% compared
to the description of the Curry report. So, from my experience,
I cannot say that this approach is "hopelessly inefficient".
> > 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.
So, it seems that we should leave this as an unspecified topic
of the report, i.e., some implementations can support
equality (and maybe comparison) between functions without
contradicting the current report. Right?
Regards,
Michael
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Fr Mär 24 2006 - 11:46:33 CET