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

From: Wolfgang Lux <lux_at_helios.uni-muenster.de>

Date: Tue, 01 Dec 1998 17:25:53 +0000

Hello Michael,

*> Your remark reminds me that I wanted to suggest a further
*

*> restriction for local pattern definitions in Curry which solves
*

*> these problems:
*

*>
*

*> All variables occurring in lhs patterns in some let/where
*

*> should occur at most once in a lhs of a local pattern declaration.
*

*>
*

*> This restriction would forbid programs like
*

*>
*

*> f x = coin where coin = 1
*

*> coin = 2
*

*>
*

*> and also your functions f1,f2,f3.
*

*>
*

*> Do you agree or is this too restrictive?
*

I would not object to this restriction. I think the examples can all be rewritten by lifting the overlapping declarations to the toplevel. Eventually a "trivial" declaration of the form

where x = y

has to be added to preserve the sharing of the local declaration. Extending your example to the case where the sharing of coin is used:

f x = g coin coin where coin = 1; coin = 2

this would have to be rewritten as

coin = 1

coin = 2

f x = y + y where y = coin

(where only the uninitiated would try to "simplify" this to f x = g coin coin.)

However, I'm a bit more worried about another point, viz. the syntactic sugar of interpreting f = g as f x = g x in case f and g are of functional type. This makes the sharing of a functional result from a non-deterministic function impossible, except if I can convince the type system into using a more general type (i.e. \forall a.a) to the local variable. With your proposed restriction, we still have for

g = incr

g = decr

f4 x = h (h x) where h = g

that f4 3 has the solutions 1, 3, and 5 in constrast to the example above which has only 2 solutions for f 3. If I really want to exclude the solution 3 (i.e. make a consistent choice for g in the program), I have to resort to something like

f5 h g x = h g g x

and

f5 (.) g 3

Regards

Wolfgang

Received on Tue Dec 01 1998 - 17:35:00 CET

Date: Tue, 01 Dec 1998 17:25:53 +0000

Hello Michael,

I would not object to this restriction. I think the examples can all be rewritten by lifting the overlapping declarations to the toplevel. Eventually a "trivial" declaration of the form

where x = y

has to be added to preserve the sharing of the local declaration. Extending your example to the case where the sharing of coin is used:

f x = g coin coin where coin = 1; coin = 2

this would have to be rewritten as

coin = 1

coin = 2

f x = y + y where y = coin

(where only the uninitiated would try to "simplify" this to f x = g coin coin.)

However, I'm a bit more worried about another point, viz. the syntactic sugar of interpreting f = g as f x = g x in case f and g are of functional type. This makes the sharing of a functional result from a non-deterministic function impossible, except if I can convince the type system into using a more general type (i.e. \forall a.a) to the local variable. With your proposed restriction, we still have for

g = incr

g = decr

f4 x = h (h x) where h = g

that f4 3 has the solutions 1, 3, and 5 in constrast to the example above which has only 2 solutions for f 3. If I really want to exclude the solution 3 (i.e. make a consistent choice for g in the program), I have to resort to something like

f5 h g x = h g g x

and

f5 (.) g 3

Regards

Wolfgang

Received on Tue Dec 01 1998 - 17:35:00 CET

*
This archive was generated by hypermail 2.3.0
: Mon Sep 16 2019 - 07:15:04 CEST
*