Inverted syntax option

[Reinier Zwitserloot]

It's an interesting idea, but as Lawrence showed, without a delimiter
resolution is complicated. I can't speak for the people who decide in the
end, but I'd eat my shoes if significant additional complexity in the
resolution process is acceptable. Method resolution is already a complex
beast that's got a lot of words dedicated to it in the JLS and is already a
fine source of puzzlers and a hefty retarding force for future language
improvements. Piling on more complexity is therefore out of the question,
most likely.

Thus, when you have no delimiters the resolution algorithm would have to be
'trivial'. Which is kind of hard to see. For example, this seems trivial:

#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 can only conclude that this idea is simply not going to work as written.
It might well work in a dynamic typing system where you don't need to know
the types of the arguments, but java's typing system doesn't work that way.

What COULD work is an offshoot that looks something like this:

#(int, int) (#1 + #2)

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.

Of course, if function types went away in favour of always fitting the
closure to an appropriate SAM type, that distinguishing problem also goes
away, but you still have to contend with the unfamiliarity and lack of
clarity, all to get only a very tiny gain in terseness.

--Reinier Zwitserloot



On Mon, Mar 15, 2010 at 8:09 PM, Bob Foster <bobfoster at gmail.com> wrote:

> John Nilsson wrote:
> > On Fri, Mar 12, 2010 at 9:02 PM, Lawrence Kesteloot <lk at teamten.com>
> wrote:
> >> ...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.
> >
> > Maybe it isn't so important. In some sense it shouldn't really matter, as
> > long as it type checks.
> > But it could be addressed with some optional delimiter:
> >
> > foo(bar(baz(#(#1 + #2)))
> >
> >> ...I also suspect you
> >> would eventually miss the named arguments, since they help document
> >> the code.
> >
> > This could be addressed with the previous proposals to support statements
> in
> > expressions:
> >
> > (int a = #1; int b = #2; a+b)
>
> Perhaps you meant this to illustrate how awkward and regressive this
> numbered-argument syntax is, and if so I applaud you for the examples.
>
> If this is a serious proposal, I suggest swapping the % character for #
> (the
> parser can figure it out by its prefix operator position) so everyone will
> understand that the new model for the Java language is the MS-DOS command
> line.
>
>   baz(%1 + %2)
>
> Bob
>
>