On Tue, Feb 24, 2015 at 9:26 PM, Matt Oliveri <[email protected]> wrote:
> On Tue, Feb 24, 2015 at 10:28 PM, Jonathan S. Shapiro <[email protected]> > wrote: > > 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. Yes. Very sorry for the typo. The intent is that **'c** unifies with 'w->'z. > 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. > I was only using this as an illustration of why the "deep arity" list is not (in general) concrete until the function itself is concretely typed. > > 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? Certainly! But if that syntax is broadly necessary, library architecture will bifurcate. My expectation is that, in practice, we can avoid the need for explicit annotation in most cases. > 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. Yes, but only for practical reasons: we want a compiler implemented before all of us are dead. If we arrive at a better understanding before I get that part of the implementation done, great. If experience tells us how to piss on my implementation constructively, great. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
