On Mon, Feb 16, 2015 at 10:17 AM, Jonathan S. Shapiro <[email protected]> wrote: > On Sun, Feb 15, 2015 at 11:11 PM, Matt Oliveri <[email protected]> wrote: >> >> On Sun, Feb 15, 2015 at 4:16 PM, Jonathan S. Shapiro <[email protected]> >> wrote: >> >> > I do not believe that >> > parenthesizing the application is a good choice, because in an >> > expression >> > like >> > >> > ((f a), (g b)) >> > >> > where g has arity 1, the programmer cannot tell whether the parens are >> > forcing a curried call or merely serving to override the usual >> > precedence >> > rules (in this case, on g, unnecessarily). Offhand, I think I would >> > prefer >> > some form of operator for this. >> >> Is this referring to my proposal? There is no curried call in ((f a), >> (g b)). > > Yes, it was, and yes, there was. The example above was given in the context > of your example (it may have been Geoffrey's). In that example, /f/ was an > arity-2 function and /g/ was an arity-1 function.
Oh, OK. In that case, (f a) is a type error. Arity-2 functions need 2 arguments. > So the first > parenthesization inside the tuple is doubling as grouping and as indicating > a partial (curried) application. Nope. The parens are just for grouping, and are unnecessary, if comma associates less strongly than application. f is applied to one argument, so it'd better have arity 1. > Perhaps I misunderstood you, but I had thought you were suggesting this use > of parenthesis to indicate that partial application was intentional. The only slightly odd thing with parens is that, for example, applying one argument, and then applying one argument to the resulting function needs parens (f x) y to disambiguate it from applying two arguments g x y. This is unlike most functional languages. You may wish to ignore its similarity to Lisp. Even here, the parens themselves are just grouping. We need to group explicitly, otherwise the first application gobbles up all the arguments. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
