On Sat, Feb 28, 2015 at 5:25 PM, Matt Oliveri <[email protected]> wrote:
> > I'm not sure
> > what is meant by the *maximum* shallow arity, so I'm not yet able to use
> > that term in a way that is consistent with you.
>
> Very simply, it's the maximum shallow arity that instances of a given
> arity-abstract type can have. Even more unambiguously: Take the set of
> all concrete instances, take the shallow arity of each, and take the
> maximum.
>
So just to confirm, I *think* this means the maximal concrete arity that
might legally specialize a given abstract arity?
> The reason why it's important that we know this is because we cannot
> apply with fewer arguments than this, or else an instance whose
> shallow arity is the maximum will come along, and our application
> would specialize to a partial application, which allocates.
Oh. Oh! No, I do not believe this is correct. Or at least I think there may
be a better way to think about it, and I also think that (if I am
understanding your term correctly) "maximum shallow arity" isn't sufficient.
I think that a better way to think about this is to imagine that an
abstract arity is accompanied by a constraint. Thus, if we see an
application for unknown function f taking the form
f a b c d
we should not merely infer
fn 'arity 'a->'b->'c->'d->'r
We should instead infer
('arity < 5) => fn 'arity 'a->'b->'c->'d->'r
And I think that we *can* apply a concrete function f_c having (say)
concrete arity 2, provided the overall type signatures unify. Allocation
may or may not happen in this case. It depends on whether f_c returns a
newly-formed closure or not. But the point is: if it returns a closure then
the allocation happened within the body of f_c as an operation explicitly
stated by the programmer, and that's okay.
Meanwhile, thank you for clarifying the rest of those definitions.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
