- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]

From: Wolfgang Lux <wlux_at_uni-muenster.de>

Date: Thu, 10 Apr 2003 09:32:04 +0200

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

Date: Thu, 10 Apr 2003 09:32:04 +0200

German Vidal 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.

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

*
This archive was generated by hypermail 2.3.0
: So Feb 05 2023 - 07:15:07 CET
*