# considered harmful [was C++11 lambdas]

[Reinier Zwitserloot]

Do you have *ANY* comments at all about the many many problems that this
mailing list uncovered with your 'preferences', or are you just whining?

A small and incomplete rehash:

1. No '.'

Java has an almost unique take on namespaces, in that in java types, methods
and variables all have their own namespace. Without that dot, the meaning of
"foo()" is ambiguous. Are you invoking the method named 'foo', or are you
invoking the closure pointed at by variable foo? The primary proposal
started out without that dot, as per the strawman. In other words, we
covered this. At extreme length. There's no point re-raising this issue
unless you come up with different solutions for the namespace issues. IIRC,
the dot has going for it:

 - No need for arbitrary ordering of namespaces in case foo is both a method
and a variable.
 - Closures in java are to a smallish extent shoehorned in. They are unique
things that aren't exactly like methods, so their invocation should look a
little different.

These advantages were deemed superior to the advantage that dotless
invocation has, which one dot less clutter at the cost of syntax ambiguity.

2. "Actual closures"

The word 'closures' is pretty meaningless. It has a well defined term in the
academic sense, and, frankly, its definition is pretty well defined in the
dictionary sense too, *but*, the vast majority of java programmers have been
abusing the term to mean something different. At any rate, whining about
"actual closures" misses the point completely. Project Lambda's aim is to
create syntax that makes it easy to write a bunch of code that's bundled up
into a reference so that you need not execute it on the spot, but can
instead hand it off to for example another method, with as primary use case
extra-jsr166y a.k.a. ParallelArrays. From the outset (the outset being Mark
Reinhold's strawman at Devoxx '09) Project Lambda did not aim to add
concepts like keeping control statements such as 'break', 'continue' and
'return' transparent. The aims of Project Lambda have not changed since its
inception. Possibly you were just confused as to what they were.



On Mon, Mar 15, 2010 at 11:57 PM, Rémi Forax <forax at univ-mlv.fr> wrote:

> Le 15/03/2010 23:27, Bob Foster a écrit :
> > Harmful because it's unpleasant to look at and leads to indecipherable
> > code. Every time someone proposes adding another #, the syntax gets
> > uglier and less readable.
> >
> > I apologize for coming to this point rather late, but frankly once I
> > read the # proposal and realized no one intended to implement actual
> > closures, I decided the whole project was a plot to convert Java
> > programmers to Scala and my mind turned to more pleasant things. This
> > was a mistake, and Remi Forax's excellent counter-proposal has
> > inspired me. Why _not_ try something simpler?
> >
>
> Yes, a supporter.
>
> > I have a (very) few nits to pick with Remi's proposal:
> >
> > - int(int) is a function type, not a function.
> >
> > - the . has no place in function call syntax; functions are not methods.
> >
>
> It will be cool to be able to call a function only by its name
> but it doesn't seem possible to twist the JLS invocation rules
> to do that (see the archive of this list for more info).
>
> > - I quite like the ( expr ) syntax when a function body is only a
> > single expression, but it's not essential and if it were adopted
> > should be extended to methods for consistency.
> >
> > - Java doesn't have type inference elsewhere, so it seems inconsistent
> > to have it for functions. However, if it was going to be part of the #
> > syntax, it should be allowed here, too, as Remi originally proposed,
> > and extended to methods, as well.
> >
>
> Java has type inference when resolving generic method calls and
> when using the diamond operator.
>
> > The whole proposal works syntactically because currently the
> > construction Type() never appears in a valid program except after new.
> > So as long as new doesn't pollute anonymous functions (a separate
> > thread), function types are unambiguous to both the compiler and
> > readers.
> >
>
> [...]
>
> Rémi
>
>