Lambda evaluation - postfix or prefix?

[Rémi Forax]

I prefer a dot syntax, something like

aLambdaThatReturnsALambda.do().do();

Ok, calling a lambda is important but I've always think that if you want
to introduce an operator in a language it has to be self-describable.
By example, I like the use of arrow in Go to put or take value from a 
channel.
'*' is too overloaded for me.
And please don't forget that for average C programmer '*' means pointers
and there is no pointer in Java (try to google it :)

Rémi

Le 29/01/2010 00:36, John Rose a écrit :
> On Jan 28, 2010, at 3:01 PM, Lawrence Kesteloot wrote:
>
>    
>> The * is optional, and if you use
>> it you must enclose it and the function expression in parentheses.
>>      
> Right.  Citing C as a precedent here is pretty weak, since many C programmers prefer the more streamlined style fptr(arg).
>
> If there has to be extra syntax (and I accept that this is the case), let's put it next to the pre-existing required syntax parts, i.e., the open and close parentheses.
>
> On Jan 28, 2010, at 2:32 PM, Lawrence Kesteloot wrote:
>
>    
>> Calls to functions returned from calls to functions are
>> vastly less common than calls to functions, and the syntax should
>> optimize for the latter.
>>      
> Actually, in Java the ratio you refer to is 0/0, so we can argue all day about whether it is vast or miniscule.  In Haskell multiple application is as common as multi-argument method calls in Java.  In C it is uncommon precisely because the lack of closures makes it useless.  In Java it is likely to be the basis of chained notations akin to stringBuffer.append(x).append(y), but more concise.
>
> But I agree with Neal that composability is an important test, a priori.
>
> In this case, we are looking at syntaxes which require tokens before the function, between the function and the argument list, and after the function.  Such syntaxes might look cute in the "hello world" use case, but won't wear well when you start building complicated expressions.  Just from a parsing point of view they are un-economical.
>
> -- John
>
>