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. > > >> > 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. > > 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. Types and type resolution exist in service of correct and maintainable programs. They are not an end in themselves. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
