Specialisation means to alter the function definition (as in C++ template specialisation) or are we running across terminology differences?
So when shap says function specialisation, to me that means changing the function definition via AST rewrite (inserting or removing lambdas)/to change the type. You could end up with multiple versions of the same function definition taking different arities. If you ignore the optional alias, we have to know the concrete arity of imported functions because we do not have access to the definitions to specialise them. We have to declare the type to allow separate compilation (and stable module interfaces). Keean. On 20 Feb 2015 08:24, "Matt Oliveri" <[email protected]> wrote: > On Fri, Feb 20, 2015 at 3:15 AM, Keean Schupke <[email protected]> wrote: > > 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. > > If that is how arity specialization works, I misunderstood it pretty > badly. I thought function definitions determine concrete arity, never > application. That's actually what my second question pertains to: > whether that's always what we want. Also, I don't think Shap decided > to use your idea to import functions at a certain type. (Unless you > mean specialize them to a certain type, which anyway happens > automatically.) > _______________________________________________ > 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
