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

From: Wolfgang Lux <wlux_at_uni-muenster.de>

Date: Sat, 19 Feb 2011 11:09:42 +0100

Hi Sebastian,

*> I thought that the difference between the expressions (=:= e) and
*

*> (\x -> x =:= e) is only observable in the context of encapsulated
*

*> search but just noticed that it is observable in ordinary Curry
*

*> programs too (using both PAKCS and MCC).
*

*>
*

*> "Each right section (op expr) is transformed into the lambda
*

*> abstraction (\x->(op) x expr) where x is a new variable." [Report on
*

*> Curry, page 82]
*

*>
*

*> Therefore, a difference between the following two predicates should
*

*> not be observable:
*

*>
*

*> partial = (=:= coin)
*

*> lambda = (\x -> x =:= coin)
*

*>
*

*> The following function computes two solutions to a given predicate:
*

*>
*

*> twoSols p | p x & p y = (x,y)
*

*> where x,y free
*

*>
*

*> It can be used to observe a difference between 'partial' and 'lambda':
*

*>
*

*> cyi> twoSols partial
*

*> (0,0)
*

*> More solutions? [Y(es)/n(o)/a(ll)]
*

*> (1,1)
*

*> cyi> twoSols lambda
*

*> (0,0)
*

*> More solutions? [Y(es)/n(o)/a(ll)]
*

*> (0,1)
*

*> More solutions? [Y(es)/n(o)/a(ll)]
*

*> (1,0)
*

*> More solutions? [Y(es)/n(o)/a(ll)]
*

*> (1,1)
*

*>
*

*> It seems related to the 'fcoin' example of the Toy community [1]
*

*> which lead to removing the mention of eta-expansion from the Curry
*

*> report. Is it a known issue that neither PAKCS nor MCC conform to
*

*> the Curry report regarding right sections?
*

*>
*

*> [1]: http://www.informatik.uni-kiel.de/~curry/listarchive/0499.html
*

thanks for this interesting example. Indeed, I wasn't aware that the

report specifies the translation of sections in that way. MCC has

always been translating right sections (`op` e) into (Prelude.flip op

e), as this translation seems more natural to me. IMHO, simple

syntactic sugar like sections should not shift expressions into a new

scope. As your example shows, this can break sharing in a non-obvious

way.

Incidentally, the current translation of sections in the report is

rather inconsistent. A right section (`op` e) is transformed into (\x -

* > x `op` e), i.e., e might be evaluated more than once, but a left
*

section (e `op`) is transformed into ((op) e), i.e., e is evaluated at

most once. Before changing MCC in any way, I'd prefer having the

report specify the translations of left and right sections

consistently. Either

(e `op`) = \x -> e `op` x

(`op` e) = \x -> x `op` e

or

(e `op`) = (\f x y -> f x y) (op) (e)

(`op` e) = (\f x y -> f y x) (op) (e)

Just for reference, the former is used in the Haskell report, but then

it makes only a difference w.r.t. efficiency if sharing is broken in

Haskell. As noted above, I'd prefer the report to use the second

transformation, which has the additional advantage that no name

captures are possible. A compiler can always optimize that

specification when op and/or e are constants or known to compute only

one solution.

Regards

Wolfgang

_______________________________________________

curry mailing list

curry_at_lists.RWTH-Aachen.DE

http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry

Received on Sa Feb 19 2011 - 18:57:54 CET

Date: Sat, 19 Feb 2011 11:09:42 +0100

Hi Sebastian,

thanks for this interesting example. Indeed, I wasn't aware that the

report specifies the translation of sections in that way. MCC has

always been translating right sections (`op` e) into (Prelude.flip op

e), as this translation seems more natural to me. IMHO, simple

syntactic sugar like sections should not shift expressions into a new

scope. As your example shows, this can break sharing in a non-obvious

way.

Incidentally, the current translation of sections in the report is

rather inconsistent. A right section (`op` e) is transformed into (\x -

section (e `op`) is transformed into ((op) e), i.e., e is evaluated at

most once. Before changing MCC in any way, I'd prefer having the

report specify the translations of left and right sections

consistently. Either

(e `op`) = \x -> e `op` x

(`op` e) = \x -> x `op` e

or

(e `op`) = (\f x y -> f x y) (op) (e)

(`op` e) = (\f x y -> f y x) (op) (e)

Just for reference, the former is used in the Haskell report, but then

it makes only a difference w.r.t. efficiency if sharing is broken in

Haskell. As noted above, I'd prefer the report to use the second

transformation, which has the additional advantage that no name

captures are possible. A compiler can always optimize that

specification when op and/or e are constants or known to compute only

one solution.

Regards

Wolfgang

_______________________________________________

curry mailing list

curry_at_lists.RWTH-Aachen.DE

http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry

Received on Sa Feb 19 2011 - 18:57:54 CET

*
This archive was generated by hypermail 2.3.0
: Do Jun 20 2024 - 07:15:11 CEST
*