On Tue, Feb 24, 2015 at 7:47 PM, Jonathan S. Shapiro <[email protected]> wrote: > On Mon, Feb 23, 2015 at 12:57 PM, Matt Oliveri <[email protected]> wrote: >> Before I forget, another question I have about the notation is how to >> read off the maximum arity when the return type is a variable. > > You can't, because the maximum arity (which I take to mean the sum of the > list elements in your lists] is underspecified until the return type is > concretized. It can become sufficiently specified sooner, but there is no > guarantee that it will.
Well maybe there's some subtlety to your proposal that I missed, but here's my take: No, the maximum arity is the maximum shallow arity of functions that can unify with it. It's inferred from the number of arguments applied. So like: f 1 2 we infer f has type (fn 'arity Nat->Nat->'a), right? But the maximum arity is 2. We cannot unify with (fn 3 Nat->Nat->String->Float) because then (f 1 2) was a partial application, and allocates a (String->Float). But it sure looks like we can. In other words, I assumed your arity-abstract function types always have maximum arities, but your notation didn't make them unambiguous. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
