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.
PKE From: bitc-dev [mailto:[email protected]] On Behalf Of Keean Schupke Sent: Tuesday, February 24, 2015 2:10 PM To: Discussions about the BitC language Subject: Re: [bitc-dev] Arity inference at call (application) sites On 24 February 2015 at 22:01, Keean Schupke <[email protected]<mailto:[email protected]>> wrote: On 24 February 2015 at 21:29, Jonathan S. Shapiro <[email protected]<mailto:[email protected]>> wrote upcast1_1to2 f = \x y.(f x) y downforce2to1_1 f = \x.\y.f x y The downforce example, at least, is a trivial lambda having no escaping closure. That one is okay. The upcast example uses a lambda whose closure escapes. That one is *not* okay. I am surprised either of these are problematic, they are just function definitions? Are there restrictions on how you can use lambda's in BitC? To clarify, if we explicitly write these functions then the lambda's give the functions permission to allocate, so they are both safe, they both may allocate, but thats okay as any function with a lambda is going to allocate? implicit coercion is something different, however the whole point of arty-abstract functions is you can make them concrete with different types. This operation is equivalent to a coercion, however, you don't want to introduce implicit lambdas, so the coercion is only safe in one direction (applying curried functions to multiple arguments). If any of this is unsafe I would like to see an explanation of why, because I must be misunderstanding something if this is the case. Keean.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
