On Mon, Feb 16, 2015 at 12:54 PM, Geoffrey Irving <[email protected]> wrote:
> On Mon, Feb 16, 2015 at 12:49 PM, Jonathan S. Shapiro <[email protected]> > wrote: > > > In this scenario, we have adequate information at the definition site > and in > > the written form of the type to determine what the arity must be, but we > do > > NOT have enough information at the application site. Given a procedure: > > > > def perverse f a b = f a b > > > > we cannot determine whether f has type fn 'a -> (fn 'b -> 'c) or > > alternatively has type fn 'a 'b -> 'c > > It might be reasonable to extend this as you say to support automatic > conversion, but it does introduce a weird asymmetry where *fewer* > arguments are disallowed but *more* arguments are fine. If more is > fundamentally easy to implement and understand, while fewer is not, > this asymmetry might be reasonable, but it seems odd. > I'm not seeing that. However the application is parenthesized due to arity, the number of arguments present still must satisfy the function type. Actually, I think you may have it backwards. If we admit this peculiar form of generalization, *fewer* arguments are OK. In particular: def f x y = lambda z { return x + y + z; } can be applied correctly as either "f u v" or "f u v w". The requirement would be that all applications must satisfy the natural arity of the function being applied; we do not inject lambdas implicitly. I grant that that outcome may have puzzling consequences for the user, so perhaps it will turn out not to be wise. I'm just saying I think it can be done. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
