# considered harmful [was C++11 lambdas]

[Bob Foster]

On Mon, Mar 15, 2010 at 4:33 PM, Reinier Zwitserloot
<reinier at zwitserloot.com> wrote:
> 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?

One person's opinions are another's whining, whatever. I have a day
job, so I get the digest and don't follow this list moment by moment.
If someone copies me, I reply.

I've already apologized for coming late to the party. Once is enough.

> 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?

Agreed that within a class a reference to a method and a call through
a variable of function type with the same number and type of arguments
would be ambiguous. Using . as a prefix operator for indirect function
calls with that issue is as good a device as any. You still have a
problem with references to static function variables within a class
and references outside the class, unless the proposal is to double up
the dots, like:

A..foo()
a..foo()

Regardless, such notation should be required _only_ if the call would
be actually ambiguous, a fairly minor use case. Inside a class, a
field name is not required to be qualified by 'this' unless necessary
to disambiguate the reference; a static method name is not required to
be qualified by the class name unless necessary to disambiguate from a
non-static method. This should be treated the same.

The example I was looking at, however, involved only function type
arguments, and I see no reason to saddle references to argument names
or local variables with gratuitous dots. As long as "inner functions"
can only be defined through variables, there is no namespace issue and
the scope rules handle the rest.

> 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.

Ah, deemed.

> 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.

I agree it's pretty meaningless in this forum, and I wish you would
stop referring to functions as closures. If nobody agrees what a
closure is, it's insulting.

If you care, though, I mean closures as they are meant, according to
Wikipedia, in computer science: "a closure is a first-class function
with free variables that are bound in the lexical environment." When I
say that the proposal doesn't do real closures what I mean is it does
lexically closed named constants. Better than nothing but a bit
tedious to work around by hand.

(Even considering break, etc. must mean someone confuses closures with
Smalltalk blocks and their spawn.)

Bob

>
>
> 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
>>
>
>