> That is the right kind of "specialization". Good.
> The functions definitions that are changed are the functions with > calls to arity-abstract functions. Function definitions themselves are > never arity-abstract in Shap's scheme. It turns out no, you never mess > with lambdas. You mess with applications to generate calls for the > right arities. Specialization means there will be multiple low-level > definitions of a function, but they will all have the same arity and > only differ in how they call other functions. There is no reason not to specialise a function with different arities. Based on the subtype relation you can have: f x y = x + y Would get the inferred type: fn 'a -> fn 'a -> 'a, so you can use it in a curried way if you like, but if you supply both arguments you can specialise the definition to the least general subtype, IE: fn 'a 'a -> 'a. You benefit from the efficiency of a single call with both parameters, without losing the ability to partially apply. > There are no optional aliases, and we know the arity of imported > functions because importable functions are defined at the toplevel of > some module, and thus have a known arity. Let's forget about optional aliases to avoid confusion. I was thinking of having import and export statements, so in one module you do: export f :: fn a' b' -> c' And in the other: import :: fn a' b' -> c' But its probably better to import modules and use the exported typed to cut down on typing. Especially if you have module type signatures separate from their (possibly multiple) implementations. Keean.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
