On 24 February 2015 at 22:01, Keean Schupke <[email protected]> wrote:
> > > On 24 February 2015 at 21:29, Jonathan S. Shapiro <[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
