Re: Committed Choice (Was: Summary of changes)

From: Wolfgang Lux <>
Date: Mon, 06 Dec 2004 16:17:47 +0100

German Vidal wrote:

> I don't think so. The normalization in [AH+02] is only concerned
> with non-variable arguments in constructor or function applications.
> I.e., it only introduces new lets to ensure that all arguments
> are variables but it does not move existing lets outwards (nor
> inwards, BTW). So the normalization of oneCoin is:
> oneCoin = let y = let x free in (coin x,x)
> in commit y
> which would work fine.

You are right. I've mixed up normalization and lifting (which isn't
performed in [AH+02]).

> Indeed, I wonder why MCC moves outwards the let expression in this
> case. I know there are some cases where moving let bindings outwards
> may be useful (e.g., the full laziness transformation), but I think
> that the usual applicability conditions do not hold for oneCoin.

I should have checked better before posting as it turns out that MCC
does not lift the inner let in this example. Nevertheless, I do not
see why this lifting should not be possible. In fact, it seems that
for the semantics presented in [AH+02], the expressions
   let x2 = (let x1 = e1 in e2) in e3
   let x1 = e1 in let x2 = e2 in e3
are equivalent in the sense that they compute the same result. This
also holds for the case x1 = x1 representing an unbound variable.
Obviously, x2 shouldn't occur free in e1, but AFAIR you did not
consider recursive bindings in [AH+02] anyway.

It also seems that one could generalize this equivalence to the
concurrent case provided that only one thread is ever going to
evaluate x2 and all other computations demanding the value of
x2 are blocked while this evaluation is performed.

> What's the reason to apply this let-floating transformation here?

As I said, MCC actually doesn't perform this let-floating transformation
and I have to admit that floating a free variable outwards doesn't make
much sense to me. Nevertheless, I believe that it is a valid
a compiler could perform.


curry mailing list
Received on Mo Dez 06 2004 - 16:32:15 CET

This archive was generated by hypermail 2.3.0 : Do Jun 13 2024 - 07:15:06 CEST