On Fri, Feb 20, 2015 at 4:00 AM, Keean Schupke <[email protected]> wrote: > >> 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.
Type theoretically, you're right. But if definitions can be arity-abstract, then 1. There is once again the question of how we pick concrete arities. In Shap's proposal it _was_ the definitions doing the picking. 2. Without further discussion, there is the fear that a closure allocation will somehow be introduced without it being clear from either the definition or the application, because the definition looks arity 2, but gets specialized to arity 1. I want to talk about this, but please wait until I bring it up with a use case I have. I want to understand the basic system before we go extending it. >> 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. There is nothing to be confused about. Shap didn't say anything about optional aliases. They aren't supported. > 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. That imported definitions would have the same type they were exported at is what everyone has been assuming, I figure. Only you proposed anything different. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
