German Vidal wrote:
> On Mon, 7 Apr 2003, Michael Hanus wrote:
>
>> [...]
>>
>> I have looked at many Curry programs and I have the feeling
>> that multiple guards are almost always used with Boolean constraints.
>> Thus, this change should have no influence on most programs.
>>
>> Please let me know if you have other experiences or arguments
>> in favor of the current definition. Otherwise, I'll introduce
>> this change in the next update of the Curry report.
>
> I have checked all the Curry programs we developed, and there are no
> program rules with multiple guards of type "Success" in them..
> Thus I agree on your suggested change.
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.
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
Select a local pattern declaration which contains only argument
variables from the main function's left-hand side in the expression,
i.e., the rule has the form
l = C[let { decls_1; p = e'; decls_2 } in e]_p
with free(e') \subset free(l). Then transform this rule into the rules
l = C[f' x_1 ... x_k e']_p
f' x_1 ... x_k z = f'' x_1 ... x_k (f_1 z) ... (f_m z)
f'' x_1 ... x_k y_1 ... y_m = let { decls_1; decls_2 } in e
f_1 p = y_1
...
f_m p = y_m
where x_1 ... x_k are all the variables occurring in l, y_1 ... y_m
are all the variables occurring in p, z is a new variable symbol and
f', f'', f_1 ... f_m are new function symbols. Repeat this step until
all local pattern declarations are eliminated.
This translation can be optimized in a few special case. If p is just
a
variable the function f' is not needed and the definition of l can be
simplified into
l = C[f'' x_1 ... x_k e']_p
Similarly, when e' is a variable the function f' is also not needed
and
the definition of l can be replaced by
l = C[f'' x_1 ... x_k (f_1 e') ... (f_m e')]_p
Regards
Wolfgang
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Do Apr 10 2003 - 09:56:43 CEST