Re: Committed Choice (Was: Summary of changes)

From: German Vidal <>
Date: Thu, 02 Dec 2004 20:56:18 +0100 (CET)

On Thu, 2 Dec 2004, Wolfgang Lux wrote:

> However, this means that
> coin 0 = success
> coin 1 = success
> oneCoin = commit [let x free in (coin x,x)]
> will not work. At least it would not work with MCC because oneCoin
> is transformed into let x free in commit [(coin x,x)], for which
> the variable shared between the constraint and the expression is
> obviously defined before commit is evaluated. Note that the
> normalization in [AH+02] will transform oneCoin in a similar way.

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.

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.

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


curry mailing list
Received on Fr Dez 03 2004 - 08:49:32 CET

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