On Mon, 6 Dec 2004, Wolfgang Lux wrote:
> > 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
> and
> let x1 = e1 in let x2 = e2 in e3
> are equivalent in the sense that they compute the same result.
Right, I also think this transformation should preserve the
semantics.
> 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.
Well, we do accept recursive bindings in [AH+02]. The only point
is that, in contrast to [Launchbury 93], we do not detect
black holes due to recursive bindings. However, this has no impact
on our semantics since black holes produce no value anyway.
> > 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
> transformation a compiler could perform.
Yes, I agree with you. In fact, I also think that the notion of
'local variable' could be dangerous. There are many let-floating
transformations that move let bindings outwards/inwards (the GHC
compiler applies some of them). While these transformations are
semantics-preserving, they could change the notion of 'locality'.
I don't see a clear solution here. While the requirement of not
binding variables that are not *local* to the constraint/expression
pair is reasonable, it is also too operational. In fact, requiring
that all Curry compilers/transformers do not apply let-floating
transformations is clearly too restrictive. I think that in this
case we should consider Wolfang's alternative formulation even if
this feature is seldom used..
Cheers,
German
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Di Dez 07 2004 - 09:14:20 CET