The only possible problem with modeling multi-arg functions as functions taking a tuple is that the tuple might be boxed, in which case it's not the efficient calling convention you want. You might be able to convince Shap to treat multi-arg functions as functions taking an _unboxed_ tuple though.
Similar story for modeling functions with named args as a function taking an unboxed record. These ideas seem good to me. Shap expressed concern about dividing the users over tuple vs. curry-looking syntax. My recommendation to use Lispy call syntax might help with that: function calls wouldn't look tuplized even though they essentially are. No one would probably prefer truly curried functions when it isn't needed, because they would require extra parens. On Thu, Feb 12, 2015 at 12:21 PM, Keean Schupke <[email protected]> wrote: > 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. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
