Inverted syntax option

[John Nilsson]

On Mon, Mar 15, 2010 at 9:09 PM, Reinier Zwitserloot <
reinier at zwitserloot.com> wrote:

> #1 + #2
>
> but it actually isn't. This looks like a single closure that adds argument
> number 1 and argument number 2 together, but it doesn't _have_ to be. It
> could also be two closures, the first one simply returning its first
> argument, the second simply returning its second, which are added together.
> Aside from having trouble even delimiting this notion, it also raises the
> question: How many arguments are there (just because #3 isn't mentioned
> doesn't technically mean it couldn't exist; plenty of times where you have a
> method that takes an argument that your implementation ends up not using,
> just so your method fits a certain interface), and what are their types?
>

I admit that I hadn't considered the case where one would like to ignore an
argument. But I see two options
a) Don't allow it. Makes things easy, but I do think it would be bad.
b) Demand some extra delimiter to wrap the lambda expression. {#1 + #2}

WRT the typing issue I don't see how you could produce an expression where
the type isn't obvious. The example with #1 + #2 is clearly an error on it's
own, with no extra context there is only Object, and Object isn't usable in
an expression involving +


in other words, remove the names of parameters, preferring numeric access
> instead. This has the benefit of producing code that's smaller, but, I doubt
> its worth the significant cost in doing it: #1 and #2 don't look anything
> like any existing java concept, whereas naming the parameters does (it looks
> like method parameters), in non-tiny closures the numbers are going to get
> confusing (for obvious reasons; a number conveys less information than a
> name. There's a reason we don't advocate naming your variables "a", "b",
> "c", after all), and now the closure's signature is hard to distinguish from
> a function type.
>

By adding extra syntax the benefit of the shorter syntax isn't there any
more, so I'd say the cost of not having names aren't worth it.

Another option is to use named arguments instead of numbered, and just say
that the order of declaration determine their position in the argument list.
{#arg1 + #arg2}  But this could prove annoying when you really wan't to use
them in a different order.

Adding more syntax just makes it ugly {#(2)arg1 + #(1)arg2} and we might
just as well go for (arg1,arg2)  => arg1+arg2


An other possibility, but I assume this is a bit esoteric for Java, would be
to match parameters on names instead of position when applying a lambda.

(int,int)->int fun = {#arg1 + #arg2};

int result = fun.(arg1=4,arg2=3)


BR,
John