Closures, too much or too little?

[mikaelgrev]

...or too late (but not really since pre Java 7 was never an option)?

I think the complexity of these proposed Closures are just right for
Java. Not so for Rock Start Programmers, but for 90% of us.

Syntax takes getting used to, but that's not biggie.

Less pitfalls than BGGA, that's what makes me happy. BGGA are perfect
for 10% of those 5 000 000 Java developers but really bad for, say,
30% since they'd had to re-learn more than they would've been able to
handle or want to.

Unless you haven't seen the spec: http://www.javac.info/closures-v06a.html

What you guys think?

Cheers,
Mikael

[Alexey Zinger]

I like.

 

Alexey

---

From: mikaelgrev <mikae...@gmail.com>
To: The Java Posse <java...@googlegroups.com>
Sent: Wed, November 18, 2009 5:13:27 PM
Subject: [The Java Posse] Closures, too much or too little?

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=.

[Andreas Petersson]

>
> Unless you haven't seen the spec: http://www.javac.info/closures-v06a.html
>

is this the spec alex miller is referring to, described at
http://puredanger.com/tech/2009/11/18/closures-after-all/ ?
or is it more like http://docs.google.com/Doc?id=ddhp95vd_0f7mcns ?

[Fabrizio Giudici]

mikaelgrev wrote:
> ...or too late (but not really since pre Java 7 was never an option)?
>

Too much for me - but above all I'd say that the decisional process is
in total confusion if first they say they'll add only project Coin
stuff, and then change their mind all of a sudden. Not a good sign, at all.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio...@tidalwave.it

[Casper Bang]

Yeah it's confusing, what made them suddenly change their mind? And
doesn't this kinda portrait Coin as a joke (not wanting to touch the
type system, only small changes etc.). It feels like a last minute
180, perhaps an attempt to keep up and not be characterized as a
legacy language? (which the blogosphere has been saturated with the
last couple of years)

/Casper

On Nov 19, 12:28 am, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
wrote:

> Fabrizio.Giud...@tidalwave.it

[Fabrizio Giudici]

Casper Bang wrote:
> Yeah it's confusing, what made them suddenly change their mind? And
> doesn't this kinda portrait Coin as a joke (not wanting to touch the
> type system, only small changes etc.). It feels like a last minute
> 180, perhaps an attempt to keep up and not be characterized as a
> legacy language? (which the blogosphere has been saturated with the
> last couple of years)
>

RIght.

BTW, it took a while for me to realize that the closures they're talking
about are neither BGGA nor CICE, but rather a simpler version based on a
proposal of Stephen Couleborne and Stefan Schulz. I've just read it - I
appreciate the minimalistic approach and it makes me worry much less
than BGGA - but it's not a finished proposal: I understand that there
are still some issues *in the specifications* to be resolved. So, we're
switching from "only small changes" to "let's put in a thing that is not
yet finished". Perhaps they plan to postpone the release?

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/people

Fabrizio...@tidalwave.it

[Serge Boulay]

What spec are you reading. It clearly says Neal Gafter in the top
right corner. From what I hear it's trimmed down version of bgga with
fcm syntax.

> --
>
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To post to this group, send email to java...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=.
>
>
>

--
Sent from my mobile device

[Mark Derricutt]

My understanding is that the goal of "coin" was small changes that
don't affect the type system. That however doesn't preclude OTHER
projects which DO touch the type system (I'm sure modularity is
touching the type system for access levels at least).

Still - will be interesting to hear there reasoning behind the
decision changes to include it.

mark

--
Pull me down under...

[Serge Boulay]

more good news .....Joe said "In terms of Project Coin, with the extended JDK 7 schedule the fate of multi-catch in the release may be reconsidered."

[Casper Bang]

True, still confusing though. The release seems to have been
postponed, JDK7 features are not final just like Coin is not final
(http://mail.openjdk.java.net/pipermail/coin-dev/2009-November/
002461.html). Does that mean the community has a new window for
contributing?

/Casper

[Fabrizio Giudici]

Casper Bang wrote:
> True, still confusing though. The release seems to have been
> postponed, JDK7 features are not final just like Coin is not final
> (http://mail.openjdk.java.net/pipermail/coin-dev/2009-November/
> 002461.html). Does that mean the community has a new window for
> contributing?
>

I'm not understanding anything - it sounds as everybody attending Devoxx
got it in a slightly changed way. An official blog post would be
welcome, at this point.

Yes, it seems that the releaseo of JDK7 has been postponed to the end of
2010. If it's the case, I understand it's a reasonable thing to re-think
the features. But, please, communicate in the proper way!

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/people

Fabrizio...@tidalwave.it

[Reinier Zwitserloot]

Clarifications straight from Mark Reinhold at the later BOF here at
#devoxx.

1. His syntax is a strawman written up in de airplane. The point is:
Mark and friends have always loved closures, they just weren't sure
java should have them, as it has such a big impact on the feel of the
language. It is NOT AN ENDORSEMENT OF FCM. He was very specific about
that. He was also quite specific about keeping it simple (willing to
give up transparency et al). The point is, yes closures, no
complexity. Syntax is a teensy tiny detail of this, so don't get hung
up on that aspect.

2. For reasons unrelated to the new language features in java7, java7
will be delayed from feb to at least sept. There's time, so, the scope
of lang features for java7 has just expanded. Thus, this is NOT AN
INDICTMENT on Project Coin at all. On the contrary, Joe Darcy is here,
and he's planning on running more coins for the future. Mark Reinhold
*SPECIFICALLY* said he does not believe the JCP is a good source of
innovation, which seems like an *endorsement* of coin.

3. During the closure wars of 2007, Mark decided to let the dust
settle and play with the prototypes.

4. As java7 is delayed A LOT (due to the apache/sun tiff in the JCP),
and even the JDK7 has been delayed quite a bit (to at least sept),
java8 is of course also going to be around much later. So, Mark has
realized that now is probably the right time.

5. Of course there will be discussion with the community about how to
do it. He's also been privately talking to lots of key players in sun,
and they've all indicated they think it's time for closures, too.

6. Parallel Arrays are involved as a driving force behind the notion
that closures are needed.

7. Another feature that's back on the 'maybe' list is multicatch:
catch (IllegalAccessException | InvocationTargetException e) { ... do
stuff with e...}

Reporting from Devoxx,

--Reinier Zwitserloot

On Nov 19, 9:26 am, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
wrote:

> Fabrizio.Giud...@tidalwave.it

[Phil]

My main issue with all of this is not what is being done, but that the
RC has slipped from February to October/November timeframe. Thread
Hijack!

[Jess Holle]

Reinier Zwitserloot wrote:
> 7. Another feature that's back on the 'maybe' list is multicatch:
> catch (IllegalAccessException | InvocationTargetException e) { ... do
> stuff with e...}
>

And the "catch ( final Throwable t ) { ... throw t; }" bit?

This would also be a big help.

--
Jess Holle

[Tim]

Did Reinhold present something different from
http://www.javac.info/closures-v06a.html ?
That appears to be a new (simplified) version of BGGA
written by Neal Gafter.

It also refers to a separate spec for "control invocation syntax".
Has anyone seen that?

--
Tim

On Nov 19, 2:16 am, Reinier Zwitserloot <reini...@gmail.com> wrote:
> Clarifications straight from Mark Reinhold at the later BOF here at
> #devoxx.
>
> 1. His syntax is a strawman written up in de airplane. The point is:
> Mark and friends have always loved closures, they just weren't sure
> java should have them, as it has such a big impact on the feel of the
> language. It is NOT AN ENDORSEMENT OF FCM. He was very specific about
> that. He was also quite specific about keeping it simple (willing to
> give up transparency et al). The point is, yes closures, no
> complexity. Syntax is a teensy tiny detail of this, so don't get hung
> up on that aspect.

> ...

[Matias Berrueta]

this is simple, and powerfull

http://code.google.com/p/lambdaj/

closures and lambda can be great

Matias Berrueta

[Reinier Zwitserloot]

Jess: Yes, 'catch (final Throwable t) { throw t}', where the throw
statement only requires handling any checked exceptions thrown by
statements in the accompanying try block, is also on the table again.

Tim: No, as I said, the syntax is just a rough sketch. Neal wrote that
changed spec AFTER the presentation, and AFTER that BOF session. It's
basically BGGA with non-local control transfer taken out. It could
form a basis for further discussion, but that is about as far removed
from an official seal of approval as any other proposal.

[Reinier Zwitserloot]

Phil: Heh, someone else created a new thread. I answered there before
I read your question here :)

NB: In case it wasn't obvious, I'm just reporting my impressions for
attending the java language-based sessions and BOFs at Devoxx.

[gafter]

On Nov 19, 9:00 am, Reinier Zwitserloot <reini...@gmail.com> wrote:
> Neal wrote that
> changed spec AFTER the presentation, and AFTER that BOF session. It's
> basically BGGA with non-local control transfer taken out. It could
> form a basis for further discussion, but that is about as far removed
> from an official seal of approval as any other proposal.

Correction: I wrote this spec about two weeks ago, before the
conference began, as part of a discussion with Gosling on a compromise
spec.

[Fabrizio Giudici]

This thing is becoming a mess of rumors and urban myths... can please somebody who's well informed (possibly one of the key players) try to recap the *correct* situation in a blog post?

-- 
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/people

Fabrizio...@tidalwave.it 

[Bill Robertson]

IIRC, I saw something about a silently generated interface as part of
the implementation the closure. Is this correct? Am I the only one
who remember some of the bad early days when oodles of tiny classes
killed your startup time?

Weren't method handles just approved for JDK 7? If so then why go
with the clunk of an interface?

Or am I completely off base?

[Bill Robertson]

Sheesh, I can't type. I was referring to the early days of Swing.
When the all of the anonymous listener classes killed your GUI start-
up time due to all of the class loading.

[Jess Holle]

Fabrizio Giudici wrote:

gafter wrote:

On Nov 19, 9:00 am, Reinier Zwitserloot <reini...@gmail.com> wrote:  

Neal wrote that
changed spec AFTER the presentation, and AFTER that BOF session. It's
basically BGGA with non-local control transfer taken out. It could
form a basis for further discussion, but that is about as far removed
from an official seal of approval as any other proposal.
      

Correction: I wrote this spec about two weeks ago, before the
conference began, as part of a discussion with Gosling on a compromise
spec.
    

This thing is becoming a mess of rumors and urban myths... can please somebody who's well informed (possibly one of the key players) try to recap the *correct* situation in a blog post?

Yes, please!

I am heartened to hear that the spec referenced is not too official yet.  I don't have any big issues with it -- but on a syntactic level I just really don't like the use of #.  It seems oddly out of place when compared to closures in other languages -- or in BGGA.

--
Jess Holle

[Neal Gafter]

On Fri, Nov 20, 2009 at 11:00 AM, Fabrizio Giudici <fabrizio...@tidalwave.it> wrote:

This thing is becoming a mess of rumors and urban myths... can please somebody who's well informed (possibly one of the key players) try to recap the *correct* situation in a blog post?

I'd like that too.  I have no idea if the spec I wrote had any influence on Reinhold's plans, or if he was even aware of it.

[Andreas Petersson]

the same argument was brought forward against scala which generates more
classes than visible for the eye when looking at the source code.
I think that is only the case if you have individual .class files
hanging around on your disk. With a single .jar file an extra class file
or two won't hurt performance.
but this is only guesswork here.

[Neal Gafter]

On Fri, Nov 20, 2009 at 11:11 AM, Jess Holle <je...@ptc.com> wrote:

I am heartened to hear that the spec referenced is not too official yet.  I don't have any big issues with it -- but on a syntactic level I just really don't like the use of #.  It seems oddly out of place when compared to closures in other languages -- or in BGGA.

This version is based on CLang, but with # instead of ^.  # is used for method references because that is the syntax in javadoc.  I would prefer ^ rather than # for function types and lambdas, but the current spec uses # for consistency with method references.

Cheers,
Neal
 

[Fabrizio Giudici]

Andreas Petersson wrote:
> the same argument was brought forward against scala which generates more
> classes than visible for the eye when looking at the source code.
> I think that is only the case if you have individual .class files
> hanging around on your disk. With a single .jar file an extra class file
> or two won't hurt performance.
> but this is only guesswork here.
>

Also, the VM of several years ago is not the VM of today (or
tomorrow...). If I'm not wrong, as part of the Jigsaw work there is
stuff for improving packing and loading code in the JRE.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/people

Fabrizio...@tidalwave.it

[Bill Robertson]

Certainly virtual machines (and real machines) are better now, but I
still don't think thats enough. One of the arguments in favor of
method handles though, is that they will let other languages perform
better because they don't have to generate classes for everything.
There's supposed to be higher overhead for classes, and the
trampolines and other tricks they need tend to defeat the optimizer.

Thanks all,
Bill

[Mario Fusco]

> This version is based on

> CLang<http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-August/002670.html>,

> but with # instead of ^.  # is used for method references because that is
> the syntax in javadoc.  I would prefer ^ rather than # for function types
> and lambdas, but the current spec uses # for consistency with method
> references.
>
> Cheers,
> Neal

Maybe I am a bit biased, but to be honest I don't see big differences
between what I developed in my project ( http://code.google.com/p/lambdaj
) and what this spec should make available in about a year (except a
nicer syntax of course). 2 years of discussions plus 1 year of delay
in the jdk7 release sounds a bit too much to have a so small set of
features.

@Gafter you wrote on the closure wiki page of lambdaj (
http://code.google.com/p/lambdaj/wiki/Closures ) that "it certainly
doesn't match any definition of "closure" that you are familiar with"
but you did not justify this sentence neither replied to my last
question. Could you clarify your thoughts about it?

Cheers
Mario

[Reinier Zwitserloot]

Okay, I made a mistake and overstated the case on Neal's proposal. I
*knew* it wasn't anything official, and I guessed he wrote it in
response to the closure proposal. That was my mistake. Everything else
in there is true.

Bill: silently generated interfaces is a part of BGGA and the CFJ
variant of BGGA. Your argument is non-sensical; all closures are
implemented at the JVM level by inner classes (unless pretty massive
JVM changes are added. The JVM changes very rarely), so there are a
gazillion little classes regardless. Does scala code run slow? Because
scala compiles down to bucketloads of tiny classes. Seems like lots-of-
classes-kill-startup-time can be relegated to the same pile as
'instantiating objects is expensive', and 'you should reuse objects'.

Jars are also going away (jigsaw), with ahead-of-time compilation and
installation offering a lot of performance improvements. Whatever
insignificant problems are associated with tiny classes now, that will
definitely offer a way to reduce that to effectively nil.

On Nov 20, 8:00 pm, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
wrote:

> Fabrizio.Giud...@tidalwave.it

[Reinier Zwitserloot]

I'm not trying to be a jackass, just giving honest advice:

Bill: Proof is in the pudding. Test it, write up a report, with pretty
charts. If you're right and there's a performance issue, take it to
the hill and start yelling. With proof, nobody can shut you up, and
discussion will commence about using method handles (I'm pretty sure I
remembed that Mark Reinhold said that would not be a good idea, but
can't remember the exact reasons he stated for this), or changing the
JVM spec, or changing sun's implementation of the JVM with more
optimizations for quickly loading AND unloading tiny one-shots like
closures, similar to generational garbage collecting. Without those
pretty charts, nobody is going to take this argument seriously, what
with scala and the like giving more than enough anecdotal evidence to
ignore you.

[hlovatt]

LamdaJ is a really good example of what can be achieved with a few
changes. Hopefully examples like this will encourage Sun to choose
something more at the CISE end of the spectrum rather than the BGGA
end.

[Mark Derricutt]

I look forward to being corrected, but all the examples I've seen of
lambaj show things like:

forEach(someCollection).setSomeMethod(withThis);

Giving to mind that forEach() returns some dynamic proxy to
someCollection that iterates over it, calling the provided method,
which is great for somethings, but in almost 99% of the times I've
wanted a nice closure based syntax for this, I've wanted to call
multiple statements on each item, or refer to the 'each' as part of
that statement, such like:

someCollection.forEach(each => each.value = each.value * 2);

Unless theres something akin to how Mockito handles parameters I don't
see how they're comparable, does lambaj allow for something like:

forEach(someCollection).setEach(each().getValue() * 2)

with each() return a ThreadLocal bound value from each iteration?

--
Pull me down under...

[Mario Fusco]

> I look forward to being corrected, but all the examples I've seen of
> lambaj show things like:
>
> forEach(someCollection).setSomeMethod(withThis);
>
> Giving to mind that forEach() returns some dynamic proxy to
> someCollection that iterates over it, calling the provided method,
> which is great for somethings, but in almost 99% of the times I've
> wanted a nice closure based syntax for this, I've wanted to call
> multiple statements on each item, or refer to the 'each' as part of
> that statement, such like:
>
> someCollection.forEach(each => each.value = each.value * 2);
>
> Unless theres something akin to how Mockito handles parameters I don't
> see how they're comparable, does lambaj allow for something like:
>
> forEach(someCollection).setEach(each().getValue() * 2)
>
> with each() return a ThreadLocal bound value from each iteration?
>
> --
> Pull me down under...

Did you give a look at this?

http://code.google.com/p/lambdaj/wiki/Closures

[Mark Derricutt]

I remember reading it awhile ago, and upon rereading it I'm still left
seeing the same problem, all of those closures just have a single
statement:

public int countFileLines(String fileName) {
lineCounter = 0;
Closure1<String> lineReader = closure(String.class); {
of(this).countNonEmptyLine(var(String.class)); }
readFileByLine(fileName, lineReader);
return lineCounter;
}


I'm not sure -how- you're pulling this off, and it sure looks like an
impressive as hell trick, but if I wanted this closure to do multiple
operations I don't see it, I assume if I had multiple of(this)
statements only the first would get associated with the closure()
definition?

I suspect if closure() was called something like "methodPointer()" it
would sit better with me, as (as far as I can tell), the intended
usage is more of that of an invokable pointer to a declared method,
and not short inline block of code (what I'd normally expect in a
closures system).

Would it be possible to just do:

public int countFileLines(String fileName) {
lineCounter = 0;
readFileByLine(fileName, of(this).countNonEmptyLine(var(String.class)));
return lineCounter;
}

and just use the of() declaration?

--
Pull me down under...

[Mario Fusco]

> I'm not sure -how- you're pulling this off, and it sure looks like an
> impressive as hell trick, but if I wanted this closure to do multiple
> operations I don't see it, I assume if I had multiple of(this)
> statements only the first would get associated with the closure()
> definition?

Actually if you try to associate more than one of() statement to the
same closure you will get an Exception. The idea is that you put the
multiple statements you want to execute in the closure inside the
method bind through the of() operator. I admit it is a matter of
tastes, but to be honest it doesn't sound so limiting to me.

> I suspect if closure() was called something like "methodPointer()" it
> would sit better with me, as (as far as I can tell), the intended
> usage is more of that of an invokable pointer to a declared method,
> and not short inline block of code (what I'd normally expect in a
> closures system).

As demonstrated by this further example taken from the mentioned wiki
page, lambdaj provides real closure, not only method pointer

--- BEGIN of example provided in the wiki page ---

The variables in the lexical scope to be closed over are the ones
contained in the object passed to the of() method. A quick example
could clarify this point. Suppose you have the following class:

public class AdderOf {
private int first;

public AdderOf(int first) {
this.first = first;
}

public add(int second) {
return first + second;
}

public int getFirst() {
return first;
}

public void setFirst(int first) {
this.first = first;
}
}

and then you define a closure as this one:

AdderOf adderOf = new AdderOf(10);
Closure<Integer> closure = closure(Integer.class) {
of(adderOf).add(var(integer.class));
}

Now if you invoke this closure by passing 5 to it:

closure.apply(5);

you will obtain 15 as expected. But after changing the property of the
closed object

adderOf.setFirst(15);

and repeating the same closure invocation you will now obtain 20.

Please let me know if this is clear and if you think it matches the
closure definition.

--- END ---

> Would it be possible to just do:
>
> public int countFileLines(String fileName) {
>     lineCounter = 0;
>     readFileByLine(fileName, of(this).countNonEmptyLine(var(String.class)));
>     return lineCounter;
>
> }

The syntax provided by the delayed closure notation is not so
different:

public int countFileLines(String fileName) {
lineCounter = 0;

readFileByLine(fileName); { of(this).countNonEmptyLine(var
(String.class)); }
return lineCounter;
}

Don't you agree?

[gafter]

On Nov 21, 2:41 pm, Mario Fusco <mario.fu...@gmail.com> wrote:
> Please let me know if this is clear and if you think it matches the
> closure definition.

As you are probably aware, a closure, by definition, captures
variables from the lexically enclosing scope. Lambdaj simply does
not. They are not, therefore, closures.

I don't mean to say lambdaj isn't useful - I'm willing to suspend
disbelief on that. They just aren't closures.

Cheers,
Neal

[hlovatt]

The AdderOf example immediately above your post shows capturing a
variable, adderOf. Sure the syntax is different, but that doesn't mean
it isn't a closure. It is the Semantics that count.

[Mario Fusco]

> As you are probably aware, a closure, by definition, captures
> variables from the lexically enclosing scope.  Lambdaj simply does
> not.  They are not, therefore, closures.
>
> I don't mean to say lambdaj isn't useful - I'm willing to suspend
> disbelief on that.  They just aren't closures.
>
> Cheers,
> Neal

Could you please better explain why the variable first of the AdderOf
class in my example cannot be considered a variable captured from the
lexically enclosing scope? I am sure that I am missing something but I
don't understand what.

Anyway I did not want to focus the discussion on my library. I was
just answering to the questions of Mark Derricutt. Sorry if I went OT.
As I stated somewhere else lambdaj is just an attempt to have in Java
a feature that I missed (and still miss) in the language. As a fan of
functional programming I would be very glad if we could have real
closures built in the language. And at that point I will be happy to
throw away lambdaj.

What I meant to underline is something different. Let me slightly
reframe the current situation in order to clarify my point of view.
Two years ago, you (of course not you Neal, it is just an hypothetical
example to illustrate my feeling) said to your employer that you were
going to add a new fantastic feature to your product. Then you spent
(wasted) the following 2 years discussing with your development team
about different proposals and evaluating their consequences. At the
end of this 2 endless years you went again to your employer saying
that you need another year to implement a "simplified" version of that
feature. I bet at this point of my hypothetical situation your boss
was running through the rooms of your office like an headless chicken
screaming loudly some non-repeatable words.

Being one of the about 5,000,000 of Java developers in the world I
suppose I am one of the employers (or customers, it is more or less
the same in this context) of people who work to define the next specs
of the language. And at the moment my only feeling is just that I
wanna scream.

[gafter]

On Nov 22, 2:45 am, Mario Fusco <mario.fu...@gmail.com> wrote:
> Could you please better explain why the variable first of the AdderOf
> class in my example cannot be considered a variable captured from the
> lexically enclosing scope? I am sure that I am missing something but I
> don't understand what.

The hallmark of a closure is that it can contain an identifier that is
bound to a name in a lexically enclosing scope.

The name "first" does not appear in the "closure", and "first" is not
a variable that is defined in a scope that lexically encloses the
"closure".

[Mario Fusco]

> The hallmark of a closure is that it can contain an identifier that is
> bound to a name in a lexically enclosing scope.
>
> The name "first" does not appear in the "closure", and "first" is not
> a variable that is defined in a scope that lexically encloses the
> "closure".

The closure is the method AdderOf.add(int second) and the name "first"
appears in its body and it is in its scope. The statements closre
() ... of(...) are just a way to build a reference to it.

[gafter]

On Nov 22, 9:30 am, Mario Fusco <mario.fu...@gmail.com> wrote:
> The closure is the method AdderOf.add(int second) and the name "first"
> appears in its body and it is in its scope. The statements closre
> () ... of(...) are just a way to build a reference to it.

Let me be more precise. /Closure/ is an informal word to describe a /
lambda expression/, which is an expression defining a function value
that may have /free variables/ (i.e., names that are not defined in
the function), which are /bound/ to variables defined in the /lexical
scope/.

Lambdaj simply does not do this. "AdderOf" is an ordinary class,
"add" is an ordinary method, and "first" is an ordinary field of that
class. There is no expression in your example that defines a function
referencing a variable from the lexically enclosing scope.

[Mario Fusco]

> Lambdaj simply does not do this.  "AdderOf" is an ordinary class,
> "add" is an ordinary method, and "first" is an ordinary field of that
> class.  There is no expression in your example that defines a function
> referencing a variable from the lexically enclosing scope.

The feature provided by lambdaj is exactly to "turn" the ordinary
method AdderOf.add() into a closure. If I am missing something please
show me a practical example where lambdaj cannot do the same of a
"real" closure with the same semantic (and probably just a slightly
uglier and more verbose syntax).

[gafter]

On Nov 23, 1:16 pm, Mario Fusco <mario.fu...@gmail.com> wrote:
> The feature provided by lambdaj is exactly to "turn" the ordinary
> method AdderOf.add() into a closure. If I am missing something please
> show me a practical example where lambdaj cannot do the same of a
> "real" closure with the same semantic (and probably just a slightly
> uglier and more verbose syntax).

Closures do not increase the set of things that can be computed in the
language; Java is Turing-complete with or without closures, so no such
example exists. Rather, they expand the kinds of abstractions that
can be conveniently expressed. See Felleison's "On the Expressive
Power of Programming Languages" <http://reference.kfupm.edu.sa/content/
o/n/on_the_expressive_power_of_programming_l_293256.pdf> for the
meaning of "expressive power" in the sense that is relevant to adding
language features.

[Mario Fusco]

> Closures do not increase the set of things that can be computed in the
> language; Java is Turing-complete with or without closures, so no such
> example exists.  Rather, they expand the kinds of abstractions that
> can be conveniently expressed.  See Felleison's "On the Expressive
> Power of Programming Languages" <http://reference.kfupm.edu.sa/content/
> o/n/on_the_expressive_power_of_programming_l_293256.pdf> for the
> meaning of "expressive power" in the sense that is relevant to adding
> language features.

When I wrote "with the same semantic" I meant that in my opinion
lambdaj's closures (or whatever you want to call them) provide exactly
the same "expressive power" of the closures defined by this last
proposal.

[gafter]

On Nov 24, 12:20 am, Mario Fusco <mario.fu...@gmail.com> wrote:
> When I wrote "with the same semantic" I meant that in my opinion
> lambdaj's closures (or whatever you want to call them) provide exactly
> the same "expressive power" of the closures defined by this last
> proposal.

Can you please show how a lambdaj "closure" can capture a (mutable)
local variable? I don't mean show how to get the same effect - I mean
how to actually reference an actual (mutable) local variable from the
scope that encloses a lambda expression?

[Mario Fusco]

> Can you please show how a lambdaj "closure" can capture a (mutable)
> local variable?  I don't mean show how to get the same effect - I mean
> how to actually reference an actual (mutable) local variable from the
> scope that encloses a lambda expression?

Sorry, but honestly I have not understood what you are asking. Can you
provide a practical example?

Anyway if you think that lambdaj's "closures" can provide the same
effect of the standard definition of a "real" closure, it means that
they can be considered closures under each practical point of view,
and then I reached my purpose.

[gafter]

On Nov 24, 12:37 pm, Mario Fusco <mario.fu...@gmail.com> wrote:
> Anyway if you think that lambdaj's "closures" can provide the same
> effect of the standard definition of a "real" closure, it means that
> they can be considered closures under each practical point of view,
> and then I reached my purpose.

If by "effect" you mean computational effect, then you achieved your
purpose before you even started because Java was already Turing-
complete. But from the practical point of view of writing
abstractions over snippets of code, that purpose has not been
furthered by lambdaj.

[Mikael Grev]

Neal, maybe a simple example of what you can't do with LambdaJ would
make things clearer?

I know about Turing completeness, but still, you can use that to say
we don't need any features at all as well.

So, what does current javac.info spec give that LambdaJ can give. I
think this is what Mario is asking.

Cheers,
Mikael

[Joe Nuxoll (Java Posse)]

Gotta say it... This is not far off from the events part of this
proposal from 2004: http://blogs.sun.com/joe/resource/java-properties-events.pdf

I just had slightly little different syntax:

-------------------------------------------------------------------------8<
// using an event keyword – method declaration same
// as everywhere else in Java (nice – my favorite)
public event boolean onMouseClicked(JButton button, Point clickPoint,
int clickCount);

// maybe specify if its multicast?
// or should they all just be considered multicast?
public multicast event boolean onMouseClicked(JButton button, Point
clickPoint, int clickCount);

// or a new [] syntax to mean “method pointer”
// note that param names are included for IDE code-
// insight information – this is more like a field declaration
public [boolean: JButton button, Point clickPoint, int clickCount]
onMouseClicked;

// a no-arg, void return method pointer
// (syntax looks silly?)
public [void:] somethingHappened;

// looks a little better using an event keyword
public event void somethingHappened();
public [Object: int feet, int inches] onJump throws VaultException;

// read-only (final) 'mouseEvents' field
public final MouseEvents mouseEvents = new MouseEvents();

// read-only 'mouseEvents' property (same thing)
public MouseEvents mouseEvents get = new MouseEvents();
-------------------------------------------------------------------------8<

- Joe

On Nov 18, 2:13 pm, mikaelgrev <mikael.g...@gmail.com> wrote:
> ...or too late (but not really since pre Java 7 was never an option)?
>
> I think the complexity of these proposed Closures are just right for
> Java. Not so for Rock Start Programmers, but for 90% of us.
>
> Syntax takes getting used to, but that's not biggie.
>
> Less pitfalls than BGGA, that's what makes me happy. BGGA are perfect
> for 10% of those 5 000 000 Java developers but really bad for, say,
> 30% since they'd had to re-learn more than they would've been able to
> handle or want to.
>
> Unless you haven't seen the spec:http://www.javac.info/closures-v06a.html
>
> What you guys think?
>
> Cheers,
> Mikael

[Josh McDonald]

Let me have a crack at it. Here's some Javascript code:

function showClosure()
{
    var localVar = 7;
    var f = function(x)
        {
            var result = x + localVar;
            localVar = 10;
            return result;
        }
    localVar = 9;
    return f;
}

var cl = showClosure();
print(cl(1)); // <-- 10
print(cl(2)); // <-- 12

Without real closures, you'll get something else other than 10 and 12, depending on where the limitations are in the bindings. You may get 8 and 9 (I /think/ this is what Obj-C blocks will do), or you may get 10 and 11.

With real closures, the local variables like localVar need to go on the heap for garbage collection instead of on the stack, which is a fairly signifigant change, which I beleive is why LambdaJ can't do it.

Disclaimer: Just because I (think I) understand it, doesn't mean I can necessarily explain it :-/

-Josh

2009/11/26 Joe Nuxoll (Java Posse) <jnu...@gmail.com>

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
"Therefore, send not to know For whom the bell tolls. It tolls for thee."

Josh 'G-Funk' McDonald
  -  jo...@joshmcdonald.info
  -  http://twitter.com/sophistifunk
  -  http://flex.joshmcdonald.info/

[Alexey Zinger]

Josh,

Let's not forget that we can do these things in Java now, even without any kind of closure syntax sugar.  If syntax makes it easier, so much the better.

public interface Closure<P, R> { public R call(P param); }

// stuff happened...

public Closure<Integer, Integer> showClosure()
{
  final int[] localVar = new int[] { 9 };
  Closure<Integer, Integer> f = new Closure<Integer, Integer>()
  {
    public Integer call(int x)
    {
      int result = localVar[0] + x;
      localVar[0] = 10;
      return result;
  };
  return f;
}
localVar[0] = 9;

// more stuff happened...

Closure<Integer, Integer> cl = showClosure();
System.out.println(cl.call(1));
System.out.println(cl.call(2));
 

Alexey
http://azinger.blogspot.com
http://bsheet.sourceforge.net
http://wcollage.sourceforge.net

---

From: Josh McDonald <jo...@joshmcdonald.info>
To: java...@googlegroups.com
Sent: Sun, November 29, 2009 8:44:14 PM
Subject: Re: [The Java Posse] Re: Closures, too much or too little?

[Josh McDonald]

Like Neal said, it's a Turing machine. Everything atop of LISP is sugar. The point is closing over the *binding* not the value. Otherwise it's simply an implied invocation parameter.

2009/11/30 Alexey Zinger <inlin...@yahoo.com>

[Viktor Klang]

Honestly, that kind of mutable state juggling simply will make multithreading even more horrid.

Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Blog: klangism.blogspot.com
Twttr: twitter.com/viktorklang
Code: github.com/viktorklang

[Mario Fusco]

> Let me have a crack at it. Here's some Javascript code:
>
> function showClosure()
> {
>     var localVar = 7;
>     var f = function(x)
>         {
>             var result = x + localVar;
>             localVar = 10;
>             return result;
>         }
>     localVar = 9;
>     return f;
>
> }
>
> var cl = showClosure();
> print(cl(1)); // <-- 10
> print(cl(2)); // <-- 12
>
> Without real closures, you'll get something else other than 10 and 12,
> depending on where the limitations are in the bindings. You may get 8 and 9
> (I /think/ this is what Obj-C blocks will do), or you may get 10 and 11.
>
> With real closures, the local variables like localVar need to go on the heap
> for garbage collection instead of on the stack, which is a fairly
> signifigant change, which I beleive is why LambdaJ can't do it.

Said that I haven't well understood in which cases could be useful to
write a piece of code like that, I can do basically the same with
lambdaj.

public class AdderOf {
private int first = 9;

public add(int second) {
int result = first + second;
first = 10;
return result;
}
}

AdderOf adderOf = new AdderOf();

Closure<Integer> closure = closure(Integer.class) {
of(adderOf).add(var(integer.class));
}

closure.apply(1); // returns 10
closure.apply(2); // returns 12

Am I losing something?

Bye
Mario

[Mario Fusco]

> Like Neal said, it's a Turing machine. Everything atop of LISP is sugar. The
> point is closing over the *binding* not the value. Otherwise it's simply an
> implied invocation parameter.

I am quite tired to read this nihilistic sentence. If everything that
matters is to have a Turing machine why do we bother ourselves with
Java or even C. Isn't assembler enough?

[Casper Bang]

Because we are developers, we invent new layers of abstractions every
so often and considers this shift in complexity, progress. :)

/Casper

[Josh McDonald]

Erm, that's kinda why I put it in there :-/

2009/11/30 Mario Fusco <mario...@gmail.com>

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Mario Fusco]

> Erm, that's kinda why I put it in there :-/

Sorry, but I am afraid I am not understanding what you are saying. Do
you agree that your example and mine do exactly the same thing or not?
Of course just a "no" it is not enough as answer :)

[Josh McDonald]

Yes I agree that your example appears to do the exact same thing, and I'm definitely willing to take your word for it. The point of the discussion isn't about using the existing ability to close over instance variables inside methods, but about adding syntax to close over method variables inside inner functions. Which Javac doesn't currently do, because it requires promoting said variables to the heap, and keeping the bindings alive when the parent method exits (in my understanding).

The reason I put in the statement about everything atop of LISP being sugar, is that the whole issue of closures is about sugar; We all know the same results can be achieved using more elaborate syntax. Showing how the same result can be computed using a more elaborate syntax doesn't really add much to the discussion of "what's a closure versus a function pointer," which is what I was weighing in on with my JS sample.

Basically, all I was trying to do was demonstrate the difference between a closure and a simple function-as-object, using some working JavaScript code and an example of what the output would be without closures. Like I said, just because I grok it (I believe), doesn't mean I can explain it well. Although I'd like to think it was a pretty decent example.

I guess you could say that a real closure promotes the *invocation* of Bar.methodFoo(10) into an "instance" of "new MethodFoo(10)", and the inner function acts as a method on the "instance of MethodFoo"

I understand that you're saying "the syntax we have is close enough, don't add a chapter to the Java spec", is that right? If so, that's a perfectly valid position to hold. Real closures are difficult to keep in your head, and I see AS3 / JavaScript people scratching their heads when the long-lived bindings make their code do things they didn't expect. When *most* Java programmers demand "closures," they mean "reified anonymous functions". I've interviewed enough "java programmers" to know that we *don't* want a lot of these people writing code full of closures. But none of them work for me ;-)

I like the idea of real closures and first-class functions in Java 7. But more important IMO is that the JVM gets a first-class "Function" interface and system, so that closures, simple function objects, and inner classes from various JVM languages can interoperate, and the standard class library gets support for said callables.

-Josh

2009/12/1 Mario Fusco <mario...@gmail.com>

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Paul King]

I am still struggling with the lambdaj syntax. Here is a Groovy closure example:

def x = 10
def incByX = { arg -> arg + x }
assert incByX(4) == 14
x = 20
assert incByX(5) == 25

What is the equivalent lambdaj?

Thanks,
Paul.

[Mario Fusco]

Hi Paul,

you can achieve the same result with lambdaj as it follows:

int x = 10;
add(int y) { return x + y; }

Closure<Integer> incByX = closure(Integer.class) {
of(this).add(var(integer.class));
}

incByX.apply(4); // return 14
x = 20;
incByX.apply(5); // return 25

Of course the syntax is not concise and elegant as it could be in
groovy or in scala, but it is the best I was able to do given the Java
constraints and limitations. As I wrote in some former post, lambdaj
has not been developed as an alternative for these languages. I am an
happy Scala developer as well, but at the moment I am obliged to use
Java during about the 80% of my working day. That's why a tried to add
a feature in my library to "simulate" what a closure can do in a real
functional language.

I suppose that I don't need to say that I'd never implement this
feature if it was already available in the language (as I think it
should be). Actually I will be happy to throw away lambdaj when (and
if) we will have closures in Java. And this is exactly the point of my
first email. I didn't want to focus the attention on lambdaj, but just
underline the fact that I am participating in discussions about
closures in Java since late 2007 and now it seems that they will be
available in late 2010 (maybe). I admit that the 2 things are hardly
comparable. Anyway I took 3 days to implement "my" closures and I
don't understand why the whole Java community needs 3 years to achieve
a more or less equivalent result.

Bye
Mario

P.S.: I am tired to fight discussing if the lambdaj's closures are
actually closures, function pointer or whatever you want. The
important thing is that people interested in them understand how they
work, their implications and their limitations in order to figure out
case by case if they could be helpful and useful in the given problem
you are going to resolve. Anyway nobody here was able to find a
practical example where a REAL closure can do something that lambdaj's
one can't. And please stop mentioning the Turing machine: nobody here
seems to be an assembler programmer even if it is a Turing complete
language as well. Lambdaj's closures ARE closures under all practical
points of view. And I am not interested in the non practical ones. I
am an engineer and a java programmer. Not a philosopher.

my 2 cents
M.

[Paul King]

It looks to me that you have a lambda function but definitely not a closure.
On the other hand, for cases where x (in the example) is a class field and
not a local variable, then by combining a lambda function with a local method
you can simulate a closure. That's a great step forward but perhaps calling
it a closure isn't the clearest name.

Cheers, Paul.

[Mario Fusco]

> It looks to me that you have a lambda function but definitely not a closure.
> On the other hand, for cases where x (in the example) is a class field and
> not a local variable, then by combining a lambda function with a local method
> you can simulate a closure. That's a great step forward but perhaps calling
> it a closure isn't the clearest name.
>
> Cheers, Paul.

So, if I can slightly rephrase your email, you are saying that lambdaj
(in some way) is able to simulate the behavior of a closure. And that
is exactly what I was trying to demonstrate too.

As for the name, which one would you like? SimulatedClosure?
ThingThatSimulatesTheBehaviorOfAClosure?
LambdaFunctionThatWhenCombinedWithAClassFieldCanSimulateAClosure? I
believe that is more important that people who want to use it
understand how it works and I hope they do after all these examples.

Cheers
Mario

[Paul King]

Block would sound better to me. In your case, the closing is only ever
done within the method and the fact that you can only deal with fields
might even cause functional formalists to argue that it isn't even
closing in that case.

Paul.