On Fri, Feb 20, 2015 at 12: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.
>
When shap says "specialization", me means the process of substituting a
concrete (or at least less abstract) type at a type variable. The result
may not be fully concrete, but it's closer to fully concrete than the
original. Whether that's done by an AST rewrite is an implementation
detail. In BitC v0, it usually involves a change to the type records rather
than a change to the AST.
Or at least, that's what shap told me he meant. :-)
> You could end up with multiple versions of the same function definition
> taking different arities.
>
There have been versions of our discussion in which this would have been
true, but it's confusing, and better avoided. The current plan is that the
native arity is determined by the number of argument patterns at the
definition. Further, we do not re-write lambdas from the right side of a
definition to the left. Thus:
def f x = lambda y { x + y)
has arity *one*. What you write is what you get.
Arity is a precondition to dealing with calling conventions, but the two
are separate. It is possible that we will decide to adopt a calling
convention in which tuple argument patterns may have their top-level
components registerized according to some deterministic calling convention
rule. There are pros and cons to that, and I actually think it is better
NOT to do that (again because of "what you wrote is what you got"). All I'm
saying is that the two issues are related, but distinct.
At an import, there may be a need to designate the calling convention for
foreign-language (more precisely: foreign runtime) functions, but that's a
separate matter from arity.
> 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).
>
In BitC that is not correct. Knowing the declaration of a function is
insufficient to specialize it in the presence of specialization over
unboxed types.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
