I think I may have missed the point here... At module boundaries you would give the type signature including grouping arguments using tuples. Any uncurrying would be local to a module.
So if a function has a type: add2 :: (int32, int32) -> int32 you would call: add (a, b) If the type was: add :: int32 -> int32 -> int32 you would call: add a b I am not sure if these functions should be overloaded (I think probably not), and I am not sure if the compiler should generate automatically curried versions of functions (probably not). I think my original point, before I wandered off into something unintentional, was that I don't see the need for arity inference, and this is because I think arity is explicit and modelled by tuples. Apologies if I got a bit lost there... Keean. On 12 February 2015 at 16:20, Jonathan S. Shapiro <[email protected]> wrote: > On Thu, Feb 12, 2015 at 7:16 AM, Keean Schupke <[email protected]> wrote: > >> > Mathematically, those two are the same. But from the practical >> standpoint of deciding how to pass arguments in a non-whole-program >> compiler, they are most definitely different. >> > >> >> But you can assume whole program if you have types at the module >> boundary, and the main program is a module. >> > When I look at the signatures at the module boundary, how do I know the > argument passing conventions for those functions? > > > shap > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
