Wolfgang Lux wrote:
> I have no objections against the change, too. But I have a minor
> question w.r.t. typing of guards. Currently sect 2.3 of the report
> says that the default type of a guard expression is Success. Obviously,
> this can no longer be the case with the proposed change if there are
> multiple guards in a rule. But what about the case of a single guard?
> Is the type of c in
> f c x | c = x
> Success or Bool? I'm inclined to favor Success here as for boolean
> guards I expect to be at least an otherwise case to be present.
I am also in favor if Success for the same reason.
> On another point, I'd like to take the opportunity to repeat my
> proposal from Oct 22nd 2001 for changing the way pattern variables
> in a local declaration group are eliminated and which did not make
> it into the current revision of the report. IIRC the feature itself
> was considered useful but my suggestion to make the auxiliary functions
> rigid that are introduced by the new algorithm was causing some
> controversy on this list. Given that the evaluation mode of defined
> functions no longer depends on their type, I now agree that its
> best to make these functions flexible and therefore omit the evaluation
> annotations. Here is the modified proposal for the subparagraph
> "Eliminate patterns" at the bottom of p. 74 in section D.8
Thanks for the updated proposal to which I agree.
The reason why your suggestion is not included in the current
revision of the report is my own demand-driven evaluation mode...
However, I am currently updating the report (also to include
case expressions) and will also add your suggestion.
Best regards,
Michael
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Do Apr 10 2003 - 13:35:42 CEST