>tuple form matches the way arguments are passed in .NET methods.

There may be some confusion between "tupled form" and "comma form" - the latter <i>could <i>be passed as a tuple or not depending on if you're calling a let-bound function or a method. (Though you do say "tuple form" and not "tuple" passing.) Eg: fn 1 2 --> two params to let-bound fn fn 1,2 --> one param (2-tuple) to let-bound fn o.meth(1, 1) --> two params to method o.meth((1,1)) --> one param (2-tuple Tuple<int,int>) to method The first and third forms do not create tuples, and will be faster than the second and fourth, all other things being equal. It would be less confusing (and allow some forms w/o parens where parens are needed now) if the typle-creating operator was not "," but let's say, "@" - but the comma matches long-standing CS and maths definitions. We are allowed certain shortcuts/hybrids that complicates things: o.meth 1 --> shortcut (no parens) one param to method 1 |> "123".Substring (1,2) |> "123".Substring() I'd have to look at the IL to see if the pseudo-currying in the last two cases here is actually optimized away, which it could given that the functional objects aren't passed out of the scope of the immediate computation. Given that tuples aren't free (they take time to construct and destruct and memory allocated, even if the .Net MM is very good w/such short-lived objects), the rule for me whether to use tuples or not is whether the args make sense as an individual "packet" of data unto itself - e.g., only use them if you already have a tuple retreived from a data-structure, or if a new tuple's lifetime is longer than entry-point of the called fn - if the tuple args are immediately unpacked, you can use two parameters to avoid overhead of the tuple. (I beleive tuples to (at least named) fn's are always tuples, and are not yet optimized away, even when immediately unpacked by tuple-args in the fn decl. and never referenced again.) In my code, I rarely use tuples as args -- except for a few cases where it's very common -- (1) in-line piplined expressions where .Zip is used to bundle-up args and pass to fun's that transform the args along the way, and (2), canonial "flyweight" data-structures such as (x,y) pairs for points, where it's easily understood what's going on, even late at night :) If you've ever programmed in Prolog, you know how it's easy to roped-in by tuples with auto-unpacking (or in the Prolog case, terms of arbitrary arity and functor name, not just ",") - but how it can also quicly become a mess. Hope that helps?