On 15 Feb 2015 05:44, "Matt Oliveri" <[email protected]> wrote: > > 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?
If it is not a foreign function its native arity is whatever is used in its definition, it could use tuples an any combination like: h :: (int32, int32) -> (int32, int32) -> int32 You would determine the native arity to be (2, 2) ie h is a function you pass two ints to, and it returns a function h' that also takes 2 ints and returns an int. > > 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? Hmm, the type system is arity aware, the exact arities are encoded in the types using tuples. With regards to automatic tupelization, you might be coding in a tupelized style and want to import a library of curried functions and not have to mix styles (or import a library of tupelized functions and use them in a curried style). Doing this automatically like F# works only one way, and seems a little permissive as automatic tupelization may not work (or even be desired in some code that relies on hoisting part of a curried application outside of a loop for efficiency). What I am suggesting is that there is a real function signature, which is that exported by the defining module, or 'C' code, and a local - alias which is the single valid signature used in type checking 'this' module. I don't like the idea of multiple overloads of what should be a single function definition with different types. Still, all of this might be a personal preference. To me there is something I dislike about each of the other approaches. What I propose avoids the bits I dislike whilst keeping the required properties. Keean.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
