Currying and the warning

[Neal Gafter]

On Fri, Nov 20, 2009 at 6:32 AM, Osvaldo Doederlein <opinali at gmail.com>wrote:

> I've just read the new proposal, seems to hit a quite good balance so I
> hope this will finally succeed. Some initial comments:
>

Thanks!

The proposal doesn't mention support for any kind of transformation. You've
> already explained that MethodHandle doesn't serve as a good basis for
> closures, but I'd like both features to be as... close as possible; and for
> closures, it makes a lot of sense to support currying because this feature
> is highly useful and it wouldn't add any significant complexity (that I can
> see) to the language. The Method Reference facility would also allow to
> curry a common method, this is a simple combination of two steps (creating a
> closure that wraps the method and then currying that closure), but would be
> more efficient if defined/implemented as a single operation (so we can just
> create a single closure that performs the currying, i.e. passing some fixed
> parameters, when delegating to the method).
>

Can you please suggest a syntax for currying?  (Especially one that adds no
complexity ;-)

The _mandatory_ warning for closures that capture non-final/shared vars
> seems too conservative. The motivation should be not freaking people who
> worry about hidden costs, but there's now plenty precedent for that, e.g.
> the silent allocations performed by enhanced-for or autoboxing, or much
> before, inner classes with their synthetic accessors to outer fields/methods
> including private ones. The language spec doesn't require mandatory warnings
> for those. I'm fully favorable to an _optional_ warning, that developers can
> activate when reviewing performance-critical code, such as the many extra
> warnings in the Eclipse compiler or tools like Checkstyle/FindBugs/PMD that
> include many detections of potential performance issues. But IMHO, making
> this warning of captures enabled by default will "taint" closures as
> something expensive, and make it more complex than necessary by requiring
> the @Shared or @SuppressWarnings("shared") annotations. (If the warning is
> optional, I guess we can omit at least @Shared from the spec.)
>

This warning is not a concession to concerns about the cost model
(performance), but based on concerns about semantics in concurrent settings.

In a secondary note, item 2 of that warning could be "The variable is not
> the target of any assignment after the closure is defined", which will avoid
> the warning for simple cases like "{ int x; if (a) x = 10 else x = 20; #()
> println(x) }" (not all developers would prefer using ?: here to enforce the
> initialization-in-declaration). Of course, the "after" in "after the closure
> is defined" is not that simple because if the closure is defined inside a
> loop, we can't have assignmaets to the variable before the closure
> definition but inside the loop; but I guess javac can already do the
> necessary flow analysis, should need it for definite assignment.
>

I'd love to see your proposed alternative specification.  As you say "after
the closure is defined" refers to the dynamic semantics of the program, but
compile-time diagnostics must be defined in terms of the static semantics.
I suspect a specification along the lines you suggest would be very
difficult.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091120/68ac787a/attachment.html