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