On Tue, Feb 24, 2015 at 2:33 PM, Keean Schupke <[email protected]> wrote:
> > > On 24 February 2015 at 22:30, Pal Engstad <[email protected]> > wrote: > >> 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 >> > > I have never mentioned automatically generating _those_functions. However > the following seems fine: > > apply f x y = (f x) y > Not necessarily, because it depends on the native arity of f. If f has native arity 2, then the required re-write to implement this would be: apply f x y => (apply (apply (\x . \y f x y) x) y) That rewrite is not legal without a region system, given the basic primitives we have been assuming. I can imagine ways to introduce a "lower level" form of apply that allows us to make the closure record explicit and stack-allocated. If that can be done, then yes, the rewrite becomes possible without violating the "no implicit heap allocation" rule. If f has a native arity of 1, then you can write it either way, but I'm not sure why that's interesting, because in general you can only *call* f according to its native arity. > And this one is not okay: > > apply f x = \y . (f x y) > Agree. In this one, the formed closure escapes, so the trick of making the closure record explicitly allocatable doesn't save us. > Do we agree you can generate the first one implicitly? > We can generate it, but in the absence of a mechanism for explicit closure records or region-based closure allocation, we can't use it within the BitC constraint. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
