On Tue, Feb 24, 2015 at 10:28 PM, Jonathan S. Shapiro <[email protected]> wrote: > On Tue, Feb 24, 2015 at 7:00 PM, Matt Oliveri <[email protected]> wrote: >> >> On Tue, Feb 24, 2015 at 7:57 PM, Jonathan S. Shapiro <[email protected]> >> wrote: >> >> > In principle, arity doesn't need to be fully known until after >> > specialization. In practice, there are many types where distinct >> > specializations produce identical code. E.g. list operations over object >> > references. It is somewhat simpler if we now in advance that such >> > specializations will all end up having the same arity and the same >> > calling convention. > > Correction: I should have written "fully concrete specialization" above. > >> Hmm. Hopefully they'd still have the same set of possible arities. > > Counter-example: > > Consider 'a->'b->'c, where 'b ends up unifying with 'w->'z in some > instantiation. If we write arities using Keean's (and others') > vector-of-shallow-arities notation, it is self evident that distinct > specializations may result in distinct *deep* arities. They will not result > in distinct *shallow* arities.
I'm guessing you mean 'c becomes a function type. I don't see why we care about 'b. Then this counter-example is solid. But it doesn't seem so bad. We might get more specializations to uncurry a function that's more curried because of our type specialization. Cool. That doesn't break any of the specializations for other types. It doesn't seem like we'd get confused and try to uncurry too much at other types. We can still use the not-too-uncurried specializations uniformly. >> >> > The reason to infer arity at applications is that it (a) it reduces >> >> > the >> >> > likelihood of library bifurcation for human reasons >> >> >> >> I don't see how. We can fully apply curried and uncurried definitions >> >> the same way, but we can only partially apply curried definitions. >> >> They're still different. >> > >> > I agree. But the bigger difference we were discussing at the time I made >> > that statement was that arity-aware application would involve passing an >> > argument tuple, with the consequence that the two types of application >> > would >> > have completely different surface syntaxes. That's a bigger inducer of >> > disparity. >> >> I see. > > To clarify: I am *speculating* about something here. I'm speculating that > partial applications constitute a small percentage of total applications, > and that requiring a syntactic signal of intent is therefore not an > overriding impediment to either camp. I have no data supporting this > hypothesis, but also no data that would discredit it. I speculate the same. But this clarification makes things less clear: Isn't it a sensible option to have an explicit partial application syntax whether we use arity specialization or not? In other words, these seem like orthogonal features, and until just now, you were talking about the other one. >> > It isn't relevant, except that the spare syntax is what is introducing >> > arity-abstract applications in the first place, which is why we need a >> > story >> > for how to specialize our way back to arity-concrete applications >> > without >> > damaging the surface syntax. >> >> So using one syntax for curried and tuplized application is your main >> reason. So maybe we shouldn't bother considering application-driven >> specialization. > > Yes and no. In the end, my motivation here is to avoid library bifurcation. > Until I understand the proposals and rationale for application-driven > specialization, I don't think they should be rejected out of hand. Also: I > haven't thought about this from the standpoint of opportunistic > optimization, which may turn out to motivate greater flexibility. > > But I do think we are in a very strong position. We have one proposal that > we now works technically, and seems likely to be "good enough". If we > implement it, and it turns out that it isn't good enough, discussions like > this one will lead us in determining how to fix the user experience. So it sounds like you want to discuss it, but you're not expecting to use it at first. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
