On Tue, Feb 24, 2015 at 4:29 PM, Jonathan S. Shapiro <[email protected]> wrote: > On Tue, Feb 24, 2015 at 7:30 AM, Matt Oliveri <[email protected]> wrote: >> >> On Tue, Feb 24, 2015 at 10:25 AM, Keean Schupke <[email protected]> wrote: >> > Huh? You need a lambda to do the reverse: >> > >> > downcast1_2to1 f x = \y . f x y >> > >> > but not the upcast. >> >> That one requires f and x to be passed at once. You'd actually have to >> write _that_ one with two lambdas. I thought you were aware of this >> issue with coercions. Here is how they'd actually be written: >> >> 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.
Wait, you're saying downforce would never heap allocate?? How has the closure not escaped when we stick (downforce2to1_1 f) into a shared data structure? _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
