If the programmer wrote `upcast1_1to2` and `downforce2to1_1`, then it would be okay.
If we automatically generate those functions, it would not be okay. PKE From: bitc-dev [mailto:[email protected]] On Behalf Of Keean Schupke Sent: Tuesday, February 24, 2015 2:28 PM To: Discussions about the BitC language Subject: Re: [bitc-dev] Arity inference at call (application) sites On 24 February 2015 at 22:24, Pal Engstad <[email protected]<mailto:[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. You can explicitly cast: (upcast1_1to2 g) (downcast2to1_1 h) And this should be okay, we are not doing anything implicit, infact these functions should work fine with entirely concrete arities, and nothing abstract at all. Is that how everyone else sees it? Keean.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
