So I guess what you're saying is to use tuplized functions at module boundaries. Then
On Sat, Feb 14, 2015 at 2:35 PM, Keean Schupke <[email protected]> wrote: > > On 14 Feb 2015 16:39, "Jonathan S. Shapiro" <[email protected]> wrote: >> >> On Fri, Feb 13, 2015 at 12:35 PM, Keean Schupke <[email protected]> wrote: >>> def f (g : 'a -> 'a -> 'a) x = g x >> >> >> Note that all you have for g here is it's type, which (per your desire) >> does not convey arity. We know enough to apply g to x. We don't know enough >> to know whether that application allocates or not. This is true because we >> don't have enough information to know whether it is a partial application. > > We know the native arity of 'g' from the module import statement. Which module import statement? g is not imported from another module, it's a local parameter. If you mean other modules' imports of f, then what is f's inter-module type so that it knows the native arity of its argument? Anyway, how is this business of using different inter-module types any better than using an arity-aware type system for compiled modules, or automatically tuplizing functions under the hood? _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
