On Tue, Feb 24, 2015 at 8:55 PM, Jonathan S. Shapiro <[email protected]> wrote: > On Tue, Feb 24, 2015 at 4:19 PM, Matt Oliveri <[email protected]> wrote: >> Here's what I think the situation is in this discussion: >> - Matt (me), Shap, and William are skeptical that subtyping can be >> implemented without introducing allocations. > > I don't agree. > > Whether we think of this as subtyping or as inequality constraints over a > Nat kind isn't the issue. In the end, if you exhaustively enumerate legal > unifications/specializations, Keean's model and mine arrive at the same > concrete results. So I don't think the issue has to do with whether the > mental model is constraints or subtypes. > ... > >> - Keean doesn't see how subtyping would make it any harder to avoid >> introducing allocations. > > Per above, I agree.
I'm surprised. So how would _you_ implement upcast1_1to2 :: fn 1 (fn 1 a->fn 1 b->c) -> (fn 2 a->b->c) upcast1_1to2 f = f ? > The issue as I see it - at least up to my current understanding of Keean's > proposal - is that the rewrites Keean seems to want to do are only legal > when the native arities involved permit them. When they do, fine. My > difficulty with his examples so far is that he never states what his native > arity assumptions are, and he also never states how the allocation strategy > for the injected lambdas required by his proposal ensures that heap > allocation need not occur. > > To be clear: I agree that given the right primitives some of the rewrites he > proposes are fine, and I think that we *could* build the right primitives to > support them. In particular, and assuming the wrong things don't escape, we > can re-write: > > f x y // for f having arity 2 > to (f x) y > > > when two arguments are actually present. But I'm not sure what purpose this > rewrite serves given that the arguments are in hand. > > What we *can't* do, again assuming that f x y has native arity 2, is > transparently accept > > f x > > > the concern is that there are a whole bunch of ways in which we could > inadvertently end up at that rewrite through successive optimizations. Your understanding of and concerns about Keean's proposal seem very different from mine. > I have yet to see a story for application-drivien specialization that makes > any sense to me. I'm sorry, because I know you have tried to put together a > coherent description, but it isn't penetrating for me. I *think* my ground > problem is that if application drives arity specialization, then we have to > be able to re-write (i.e. instantiate) the function definitions at the > selected arities. The function definitions aren't necessarily available to > us in the form of an AST, so I don't see how that's possible. > > Correction: I can see how to make function definitions available in the form > of an AST (thereby enabling instantiation), but for fully concrete functions > I think the cost of this is more than we want. It might be possible to do something about that cost, but given that your motivation for arity specialization is the resulting application syntax, it's probably not worth the trouble. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
