The way I thought this could work is that you infer the arity from the use of a function (and that arity is concrete in the type). If it is an imported or foreign function the inferred arity must match the declared arity in the import statement (which optionally could be an arity-alias) or type checking fails. For locally declared functions the definition would initially be typed as curried, and specialised versions of the definition generated for each different arity used. There would be a subtype relationship between each used different arity type and the fully curried version. So:
(fn 'a -> fn 'b -> 'c) :> (fn 'a 'b -> 'c) Obviously there are more combinations of subtypes for 3 argument functions etc. Keean. On 20 Feb 2015 08:00, "Matt Oliveri" <[email protected]> wrote: > On Thu, Feb 19, 2015 at 1:21 PM, Jonathan S. Shapiro <[email protected]> > wrote: > > All: > > > > I certainly don't want to shut anybody down, but I think we've gotten to > the > > point in this discussion where further issues may be best revealed by > trying > > to implement what we have. The main new thing we have recognized since my > > last summary is that the arity really does need an explicit "slot" in the > > function type syntax. That's very helpful, because we had sort of known > this > > and then forgotten about it. > > I actually feel kind of shut-down. Maybe I waited too long to reply, > but I'm still not clear on the details of the arity specialization > business. I have another question in the wings, but the one I asked > about arity-indexed families vs. constraints is conceptually prior. > > Your email sounds like a conclusion, but I couldn't actually tell for > sure: you are indeed planning to implement arity specialization? > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
