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. > 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. > > > In any case, do people agree that this ambiguity of interpretation exists,
No. > 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? I don't understand it yet. Maybe after I get some sleep. I thought _you_ were making the case against arity-agnostic function types, until just now, when you seem to have suddenly thought of some great trick. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
