On Fri, Feb 20, 2015 at 12:44 AM, Matt Oliveri <[email protected]> wrote:
> On Fri, Feb 20, 2015 at 3:28 AM, Keean Schupke <[email protected]> wrote: > > > 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. > > The functions definitions that are changed are the functions with > calls to arity-abstract functions. Oh. Yes. Sorry. That one *is* an AST rewrite (or at least I provisionally think so - we'll see). Since BitC v0 doesn't arity-abstract function types, it doesn't arise. What I said about generally we change the type records is correct for BitC v0. There *are* some other cases in BitC v0 where we do a type-based specialization of the AST. Mainly to distinguish the various uses of "dot". Method call vs field lookup being one example. Sub-package vs. field name being another. > 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. > Correct. Or at least that's the present proposal. > > 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). > > 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. > There *may* be an optional alias, but not for the reasons Keean originally gave. When you import functions across language boundaries, you sometimes have to deal with the fact that the respective languages have different rules about what is a legal function name. That usually requires an alias. Aliases can also come up in the context of weak symbols. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
