On Mon, Feb 16, 2015 at 3:49 PM, Jonathan S. Shapiro <[email protected]> wrote: > Arguably, we do not care. I think I could make a case here that the type we > should infer for /f/ is simply 'a -> 'b -> 'c, with the intended meaning > that we really don't *care* what the native arity of f is. If /perverse/ is > called with a function having type fn 'a -> (fn 'b -> 'c), we will perform a > type-driven specialization of /perverse/ to accept an arity-1 function. > Conversely, if /perverse/ is called with a function having type fn 'a 'b -> > 'c, will will perform a type-driven specialization of /perverse/ such that > it accepts an arity-2 function. > > It actually seems *desirable* to me that we should have a means to be > arity-agnostic, or if you prefer, generic over arity. > > Offhand, I see two issues here: > > 1. Concretization of arity isn't just a matter of specializing the function > type. It entails a type-driven AST rewrite at the application site. I see no > inherent problem with that.
OK, now I think I understand this proposal better. I have no gut-feeling objections to this. But a while back, you mentioned some fancy code generation technique that's lighter than JIT, which you were going to use for specialization. Does this AST rewrite aspect cause problems for that technique? It doesn't literally have to be an AST rewrite, I think. It could be prologue, epilogue, and call sequence placeholders to fill in. > 2. We might end up with cases where arity is bounded but underspecified. For > reasons of performance, I think the correct heuristic in the presence of > ambiguity is to prefer the largest possible arity, on the grounds that this > minimizes the number of calls. > > Hmm. Now that I think about it, I'm not sure the underspecification I'm > talking about here can ever actually occur. Ultimately, every procedure that > might be passed originates at a definition. Since type concretization > proceeds top-down from main(), I think it's the case that arity information > must necessarily propagate top-down as the types specialize. I think you are right that you could propagate all the arity information. > In any case, do people agree that this ambiguity of interpretation exists, > and that the type-driven AST rewrite is not somehow unclean? Does anybody > want to make the case that an arity-agnostic abstract function type is a bad > idea? _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
