On Tue, Feb 24, 2015 at 2:28 PM, Keean Schupke <[email protected]> wrote:
> > > On 24 February 2015 at 22:24, Pal Engstad <[email protected]> > wrote: > >> Keean: As far as I understand, the rule we are aiming for is that it is >> okay to use a lambda if the original program used a lambda, but that we >> don’t want to **implicitly** create lambda’s that create allocations. >> So, the question isn’t whether your scheme is **safe** or not (it should >> be, of course), it is whether or not it creates hidden allocations. >> > > Yes, I agree with this definition, which is why I cannot see the problem > with: > > upcast1_1to2 f = \x y.(f x) y > downforce2to1_1 f = \x.\y.f x y > > The lambda's in these function definitions are explicit, and hence should > be okay. > Yes. But I think you have forgotten why these examples were brought forward. They were brought forward to illustrate what the code is that the compiler would have to inject to manage arity disparities at application time. So these aren't programmer-introduced lambdas. In the context of our discussion they are compiler-introduced lambdas! shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
