Inverted syntax option

[Lawrence Kesteloot]

I think this approach is interesting, and perhaps some of the issues
could be worked out with clever type inference, but IMO it's a deal
breaker that it's not clear what the extent of the lambda expression
is. If you write:

    foo(bar(baz(#1 + #2)));

what is the lambda expression? It could be "#1 + #2" or "baz(#1 + #2)"
or "bar(baz(#1 + #2))" and the compiler has to guess based on the
parameters of these functions. The fact that it's not immediately
obvious to the programmer what's being passed to what makes this a
non-starter, as much as I like the nakedness of it. I also suspect you
would eventually miss the named arguments, since they help document
the code.

Lawrence


On Fri, Mar 12, 2010 at 11:31 AM, John Nilsson <john at milsson.nu> wrote:
> On Fri, Mar 12, 2010 at 1:18 PM, Alex Buckley <Alex.Buckley at sun.com> wrote:
>
>> I would call these "naked lambdas" since the expression with #
>> parameters is shorn of a signature or delimiters like {..}. But you
>> still have to pay the cost of a static type system, by casting the
>> positional parameters in order to do anything interesting with them.
>> This seems like an original, but really quite painful, idea.
>>
> Only if assigning to an Object reference.
>
> I imagine most uses of lambdas will be in arguments to methods where the
> argument type is specified. In these cases type inference should kick in and
> dictate the type.
>
> Given a method
> <T> testThat(T t, (T)->bool pred){}
>
> a call like
>
> testThat(myObj, #1.aMethod() == null)
>
> would be legal. And the type of #1 would be inferred to be the same as myObj
>
> I do agree that naked lambdas is a better name though ;)
>
> BR,
> John
>
>