Interesting message for Java, the platform, concurrency, and platform limitations (by Doug Lea)

> Hi all,
>
> This is a message of Doug Lea, recently sent to closures-dev mailing list.
>
> http://markmail.org/message/jjfesqilx5eu3wot?q=Boxing+function+types
>
> It also mentions scala/specialization, but it should be interesting
> reading for many in this list even without that reference.

Hi list,
reading that message I remembered something that I always missed in Java (at
the time I wrote my last Java code... around 1.3.1): the ability to bulk
allocate object arrays. If I know that I will use some 100.000 or more objects
(most likely simple value container) with a "no parameter" constructor why
can't I initialize the whole array in one statement, allowing the underlying
implementation do it's best to keep things fast and tightly packed in memory?

I would happily accept that such a feature might be heavily constrained (no
object type/subtype mix within the array, array immutabilty - just name it).
If it would allow for very performant calculations and memory allocations I
assume that one can find many use cases for that.
(If I remember things right, this is a rather common approach in C++/C and
suggests to me that it makes some sense).

Just a quick (and maybe wrong) thought...

Cheers
Bernd

On Fri, 2009-11-27 at 00:58 +0200, Dimitris Andreou wrote:
> Hi all,
>
> This is a message of Doug Lea, recently sent to closures-dev mailing list.
>
> http://markmail.org/message/jjfesqilx5eu3wot?q=Boxing+function+types

Yeah, I also found that thread interesting when I saw it. The message
you quoted, but also the previous message from Doug Lea on the same
thread and Neal Gafter's comments on generic specialization for Java.

"Including lambda-like closures, function types, embeddable
structs/values/tuples, improved arrays (especially 2d dense), revising
JLS exception rules to better deal with async failures, and possibly
further extensions for non-shared-memory parallelism."

How nice would that be? ;)

Best,
Ismael

  While we're dreaming, why not ask (wish or complain !! ;-) ) for struct/value
types, then you get bulk allocation not just for arrays but anywhere you want it !


  Cheers


On Fri, Nov 27, 2009 at 1:52 AM, Bernd Johannes <bjohanns@bacon.de> wrote:

> Hi all,
>
> This is a message of Doug Lea, recently sent to closures-dev mailing list.
>
> http://markmail.org/message/jjfesqilx5eu3wot?q=Boxing+function+types
>
> It also mentions scala/specialization, but it should be interesting
> reading for many in this list even without that reference.

Hi list,
reading that message I remembered something that I always missed in Java (at
the time I wrote my last Java code... around 1.3.1): the ability to bulk
allocate object arrays. If I know that I will use some 100.000 or more objects
(most likely simple value container) with a "no parameter" constructor why
can't I initialize the whole array in one statement, allowing the underlying
implementation do it's best to keep things fast and tightly packed in memory?

I would happily accept that such a feature might be heavily constrained (no
object type/subtype mix within the array, array immutabilty - just name it).
If it would allow for very performant calculations and memory allocations I
assume that one can find many use cases for that.
(If I remember things right, this is a rather common approach in C++/C and
suggests to me that it makes some sense).

Just a quick (and maybe wrong) thought...

Cheers
Bernd

  Of course since this requires an enhacement of the Java VM, this
will likely not happen anytime soon, for it seems that things have stoped
evolving since 1.5... what a shame...


2009/11/27 Maxime Lévesque <maxime.levesque@gmail.com>

  While we're dreaming, why not ask (wish or complain !! ;-) ) for struct/value
types, then you get bulk allocation not just for arrays but anywhere you want it !


  Cheers


On Fri, Nov 27, 2009 at 1:52 AM, Bernd Johannes <bjohanns@bacon.de> wrote:

> Hi all,
>
> This is a message of Doug Lea, recently sent to closures-dev mailing list.
>
> http://markmail.org/message/jjfesqilx5eu3wot?q=Boxing+function+types
>
> It also mentions scala/specialization, but it should be interesting
> reading for many in this list even without that reference.

Hi list,
reading that message I remembered something that I always missed in Java (at
the time I wrote my last Java code... around 1.3.1): the ability to bulk
allocate object arrays. If I know that I will use some 100.000 or more objects
(most likely simple value container) with a "no parameter" constructor why
can't I initialize the whole array in one statement, allowing the underlying
implementation do it's best to keep things fast and tightly packed in memory?

I would happily accept that such a feature might be heavily constrained (no
object type/subtype mix within the array, array immutabilty - just name it).
If it would allow for very performant calculations and memory allocations I
assume that one can find many use cases for that.
(If I remember things right, this is a rather common approach in C++/C and
suggests to me that it makes some sense).

Just a quick (and maybe wrong) thought...

Cheers
Bernd

On Fri, 2009-11-27 at 07:18 -0500, Maxime Lévesque wrote:
>
> While we're dreaming, why not ask (wish or complain !! ;-) ) for
> struct/value

Doug Lea mentioned that in his email.

Ismael

On Fri, 2009-11-27 at 07:24 -0500, Maxime Lévesque wrote:
>
> Of course since this requires an enhacement of the Java VM, this
> will likely not happen anytime soon, for it seems that things have
> stoped
> evolving since 1.5... what a shame...

That is not true. See the work on invokedynamic, continuations, method
handles, anonymous classes, tail calls, interface injection, etc.:

http://openjdk.java.net/projects/mlvm/subprojects.html

Sure, none of those is production-ready, but some of those should make
Java 7 and it's good to see work being done there.

Also, compressed references, scalar replacement and the G1 garbage
collector are now available in JDK 6 builds and they are all very
useful.

Best,
Ismael

  Let's hope some do come out for 1.7.
Last time I checked, closures were not going to make it in 1.7,
which made me loose hope for the java language,
fortunately Scala is there ! ;-)


2009/11/27 Ismael Juma <mlists@juma.me.uk>

On Fri, 2009-11-27 at 07:24 -0500, Maxime Lévesque wrote:
>
>   Of course since this requires an enhacement of the Java VM, this
> will likely not happen anytime soon, for it seems that things have
> stoped
> evolving since 1.5... what a shame...

That is not true. See the work on invokedynamic, continuations, method
handles, anonymous classes, tail calls, interface injection, etc.:

http://openjdk.java.net/projects/mlvm/subprojects.html

Sure, none of those is production-ready, but some of those should make
Java 7 and it's good to see work being done there.

Also, compressed references, scalar replacement and the G1 garbage
collector are now available in JDK 6 builds and they are all very
useful.

Best,
Ismael

2009/11/27 Maxime Lévesque :
>
>   Let's hope some do come out for 1.7.
> Last time I checked, closures were not going to make it in 1.7,

Did you read the mail I cited? It's a discussion where adding closures
to Java 7 is the starting point.

> which made me loose hope for the java language,
> fortunately Scala is there ! ;-)

Quoting Doug:
> Some days I think the
>Java language evolution story is just too hard,
>and that it would be more profitable to focus
>on developing other JVM-hosted languages like X10 that
>have worked out a more coherent story about it.

ps: every time someone inappropriately "looses" something, a fluffy
kitty dies painfully. please, save the kitties!

>
>
> 2009/11/27 Ismael Juma
>>
>> On Fri, 2009-11-27 at 07:24 -0500, Maxime Lévesque wrote:
>> >
>> >   Of course since this requires an enhacement of the Java VM, this
>> > will likely not happen anytime soon, for it seems that things have
>> > stoped
>> > evolving since 1.5... what a shame...
>>
>> That is not true. See the work on invokedynamic, continuations, method
>> handles, anonymous classes, tail calls, interface injection, etc.:
>>
>> http://openjdk.java.net/projects/mlvm/subprojects.html
>>
>> Sure, none of those is production-ready, but some of those should make
>> Java 7 and it's good to see work being done there.
>>
>> Also, compressed references, scalar replacement and the G1 garbage
>> collector are now available in JDK 6 builds and they are all very
>> useful.
>>
>> Best,
>> Ismael
>>
>
>

On Fri, 2009-11-27 at 08:48 -0500, Maxime Lévesque wrote:
>
> Let's hope some do come out for 1.7.
> Last time I checked, closures were not going to make it in 1.7,
> which made me loose hope for the java language,
> fortunately Scala is there ! ;-)

As Dimitris said, closures are being considered for Java 7 again (this
time with support from Sun). In any case, my objection was not about
Java. Your quote:

"Of course since this requires an enhacement of the Java VM, this
will likely not happen anytime soon,"

My objection was about the JVM. Java has been evolving very slowly
indeed even though there is hope for closures, still.

Best,
Ismael

On Fri, 27 Nov 2009 08:48:28 -0500, Maxime Lévesque wrote:

> Let's hope some do come out for 1.7.
> Last time I checked, closures were not going to make it in 1.7, which
> made me loose hope for the java language, fortunately Scala is there !
> ;-)

Last time you checked must have been before Mark Reinhold made his
announcement at Devoxx last week that the time has come for Java to have
closures (or at least lambdas). See his blog at http://blogs.sun.com/mr/
entry/closures

...Djeeezus,  if capture of non final variables are not supported,
they can't really be called closures ! Way back, anonymous classes  were
patched to support somekind of a poor man's closure, with this kind of
closure, I guess the man just cashed his paycheck from the dollar store ! ;-)

 Cheers !

Quote :

Some of the other features found in the existing proposals carry considerable additional complexity:

• Capture of non-final variables,

• Non-local transfer of control, and

• Library-defined control structures (i.e., control abstraction).

At present I see no need to add any of these to Java.

On Sun, Nov 29, 2009 at 1:14 AM, Ken Bloom <kbloom@gmail.com> wrote:

On Fri, 27 Nov 2009 08:48:28 -0500, Maxime Lévesque wrote:

> Let's hope some do come out for 1.7.
> Last time I checked, closures were not going to make it in 1.7, which
> made me loose hope for the java language, fortunately Scala is there !
> ;-)


Last time you checked must have been before Mark Reinhold made his
announcement at Devoxx last week that the time has come for Java to have
closures (or at least lambdas). See his blog at http://blogs.sun.com/mr/
entry/closures

--
Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/

Yeah, they can have function literals and function types. Just don't call them closures if they aren't.

2009/11/29 Maxime Lévesque <maxime.levesque@gmail.com>

...Djeeezus,  if capture of non final variables are not supported,
they can't really be called closures ! Way back, anonymous classes  were
patched to support somekind of a poor man's closure, with this kind of
closure, I guess the man just cashed his paycheck from the dollar store ! ;-)

 Cheers !

Quote :

Some of the other features found in the existing proposals carry considerable additional complexity:

• Capture of non-final variables,

• Non-local transfer of control, and

• Library-defined control structures (i.e., control abstraction).

At present I see no need to add any of these to Java.

On Sun, Nov 29, 2009 at 1:14 AM, Ken Bloom <kbloom@gmail.com> wrote:

On Fri, 27 Nov 2009 08:48:28 -0500, Maxime Lévesque wrote:

> Let's hope some do come out for 1.7.
> Last time I checked, closures were not going to make it in 1.7, which
> made me loose hope for the java language, fortunately Scala is there !
> ;-)


Last time you checked must have been before Mark Reinhold made his
announcement at Devoxx last week that the time has come for Java to have
closures (or at least lambdas). See his blog at http://blogs.sun.com/mr/
entry/closures

--
Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/

--
Daniel C. Sobral

I travel to the future all the time.

So then Haskell has no closures, as it has no non-final variables?

2009/11/29 Daniel Sobral :
> Yeah, they can have function literals and function types. Just don't call them closures if they aren't.
>
> 2009/11/29 Maxime Lévesque
>>
>> ...Djeeezus,  if capture of non final variables are not supported,
>> they can't really be called closures ! Way back, anonymous classes  were
>> patched to support somekind of a poor man's closure, with this kind of
>> closure, I guess the man just cashed his paycheck from the dollar store ! ;-)
>>
>>  Cheers !
>>
>> Quote :
>>
>> Some of the other features found in the existing proposals carry considerable additional complexity:
>>
>> Capture of non-final variables,
>>
>> Non-local transfer of control, and
>>
>> Library-defined control structures (i.e., control abstraction).
>>
>> At present I see no need to add any of these to Java.
>>
>>
>>
>> On Sun, Nov 29, 2009 at 1:14 AM, Ken Bloom wrote:
>>>
>>> On Fri, 27 Nov 2009 08:48:28 -0500, Maxime Lévesque wrote:
>>>
>>> > Let's hope some do come out for 1.7.
>>> > Last time I checked, closures were not going to make it in 1.7, which
>>> > made me loose hope for the java language, fortunately Scala is there !
>>> > ;-)
>>>
>>>
>>> Last time you checked must have been before Mark Reinhold made his
>>> announcement at Devoxx last week that the time has come for Java to have
>>> closures (or at least lambdas). See his blog at http://blogs.sun.com/mr/
>>> entry/closures
>>>
>>> --
>>> Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
>>> Department of Computer Science. Illinois Institute of Technology.
>>> http://www.iit.edu/~kbloom1/
>>>
>>
>
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>

Of course not. Since it doesn't have non-final variables, there is nothing it doesn't capture in the closure. Java, OTOH, has non-final variables, so making them non-capturable makes the "closure" incomplete.

2009/11/29 Ricky Clarkson <ricky.clarkson@gmail.com>

So then Haskell has no closures, as it has no non-final variables?

2009/11/29 Daniel Sobral <dcsobral@gmail.com>:
> Yeah, they can have function literals and function types. Just don't call them closures if they aren't.
>
> 2009/11/29 Maxime Lévesque <maxime.levesque@gmail.com>
>>
>> ...Djeeezus,  if capture of non final variables are not supported,
>> they can't really be called closures ! Way back, anonymous classes  were
>> patched to support somekind of a poor man's closure, with this kind of
>> closure, I guess the man just cashed his paycheck from the dollar store ! ;-)
>>
>>  Cheers !
>>
>> Quote :
>>
>> Some of the other features found in the existing proposals carry considerable additional complexity:
>>
>> Capture of non-final variables,
>>
>> Non-local transfer of control, and
>>
>> Library-defined control structures (i.e., control abstraction).
>>
>> At present I see no need to add any of these to Java.
>>
>>
>>
>> On Sun, Nov 29, 2009 at 1:14 AM, Ken Bloom <kbloom@gmail.com> wrote:
>>>
>>> On Fri, 27 Nov 2009 08:48:28 -0500, Maxime Lévesque wrote:
>>>
>>> > Let's hope some do come out for 1.7.
>>> > Last time I checked, closures were not going to make it in 1.7, which
>>> > made me loose hope for the java language, fortunately Scala is there !
>>> > ;-)
>>>
>>>
>>> Last time you checked must have been before Mark Reinhold made his
>>> announcement at Devoxx last week that the time has come for Java to have
>>> closures (or at least lambdas). See his blog at http://blogs.sun.com/mr/
>>> entry/closures
>>>
>>> --
>>> Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
>>> Department of Computer Science. Illinois Institute of Technology.
>>> http://www.iit.edu/~kbloom1/
>>>
>>
>
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>



--
Ricky Clarkson
Java and Scala Programmer, AD Holdings
+44 1565 770804
Skype: ricky_clarkson
Google Talk: ricky.clarkson@gmail.com
Google Wave: ricky.clarkson@googlewave.com

--
Daniel C. Sobral

I travel to the future all the time.

I agree that this is both odd and unfortunate. That said, there are not all
that many use cases for
closures modifying variables from the containing local scope (the class
scope is accessible and
fields modifiable) and usually good workarounds for such cases as do exist.
Non-local transfer of
control is even less problematic an omission. Other than (rare) returns
from for-comprehensions, I
can't think of the last time I've used that feature in Scala.

Lacking control abstraction is the major screwup here. Yet more reason to
consider Java 7
legacy-before-shipped.

--Dave Griffith

Daniel Sobral wrote:
>
> Of course not. Since it doesn't have non-final variables, there is nothing
> it doesn't capture in the closure. Java, OTOH, has non-final variables, so
> making them non-capturable makes the "closure" incomplete.
>
> 2009/11/29 Ricky Clarkson
>
>> So then Haskell has no closures, as it has no non-final variables?
>>
>> 2009/11/29 Daniel Sobral :
>> > Yeah, they can have function literals and function types. Just don't
>> call
>> them closures if they aren't.
>> >
>> > 2009/11/29 Maxime Lévesque
>> >>
>> >> ...Djeeezus, if capture of non final variables are not supported,
>> >> they can't really be called closures ! Way back, anonymous classes
>> were
>> >> patched to support somekind of a poor man's closure, with this kind of
>> >> closure, I guess the man just cashed his paycheck from the dollar
>> store
>> ! ;-)
>> >>
>> >> Cheers !
>> >>
>> >> Quote :
>> >>
>> >> Some of the other features found in the existing proposals carry
>> considerable additional complexity:
>> >>
>> >> Capture of non-final variables,
>> >>
>> >> Non-local transfer of control, and
>> >>
>> >> Library-defined control structures (i.e., control abstraction).
>> >>
>> >> At present I see no need to add any of these to Java.
>> >>
>> >>
>> >>
>> >> On Sun, Nov 29, 2009 at 1:14 AM, Ken Bloom wrote:
>> >>>
>> >>> On Fri, 27 Nov 2009 08:48:28 -0500, Maxime Lévesque wrote:
>> >>>
>> >>> > Let's hope some do come out for 1.7.
>> >>> > Last time I checked, closures were not going to make it in 1.7,
>> which
>> >>> > made me loose hope for the java language, fortunately Scala is
>> there
>> !
>> >>> > ;-)
>> >>>
>> >>>
>> >>> Last time you checked must have been before Mark Reinhold made his
>> >>> announcement at Devoxx last week that the time has come for Java to
>> have
>> >>> closures (or at least lambdas). See his blog at
>> http://blogs.sun.com/mr/
>> >>> entry/closures
>> >>>
>> >>> --
>> >>> Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
>> >>> Department of Computer Science. Illinois Institute of Technology.
>> >>> http://www.iit.edu/~kbloom1/
>> >>>
>> >>
>> >
>> >
>> >
>> > --
>> > Daniel C. Sobral
>> >
>> > I travel to the future all the time.
>> >
>>
>>
>>
>> --
>> Ricky Clarkson
>> Java and Scala Programmer, AD Holdings
>> +44 1565 770804
>> Skype: ricky_clarkson
>> Google Talk: ricky.clarkson@gmail.com
>> Google Wave: ricky.clarkson@googlewave.com
>>
>
>
>

I'd say that it has closures but doesn't capture non-final local variables.

There are garbage collection issues involved in capturing non-final
locals. Consider:

int x;

Runnable a = #() { x++; };
Runnable b = #() { x++; };

return b;

Should x be stored in the enclosing object (and hence the enclosing
object would need a collection), in the first Runnable, a, or in the
second Runnable, b? Whichever you choose could cause an object to
live longer than it would if x was final. There may be an option I
haven't thought of.

A rule needs to exist, and it needs to be simple enough to follow for
programmers concerned about unnecessary references.

[I haven't checked what Scala does]

2009/11/29 Daniel Sobral :
> Of course not. Since it doesn't have non-final variables, there is nothing it doesn't capture in the closure. Java, OTOH, has non-final variables, so making them non-capturable makes the "closure" incomplete.
>
> 2009/11/29 Ricky Clarkson
>>
>> So then Haskell has no closures, as it has no non-final variables?
>>
>> 2009/11/29 Daniel Sobral :
>> > Yeah, they can have function literals and function types. Just don't call them closures if they aren't.
>> >
>> > 2009/11/29 Maxime Lévesque
>> >>
>> >> ...Djeeezus,  if capture of non final variables are not supported,
>> >> they can't really be called closures ! Way back, anonymous classes  were
>> >> patched to support somekind of a poor man's closure, with this kind of
>> >> closure, I guess the man just cashed his paycheck from the dollar store ! ;-)
>> >>
>> >>  Cheers !
>> >>
>> >> Quote :
>> >>
>> >> Some of the other features found in the existing proposals carry considerable additional complexity:
>> >>
>> >> Capture of non-final variables,
>> >>
>> >> Non-local transfer of control, and
>> >>
>> >> Library-defined control structures (i.e., control abstraction).
>> >>
>> >> At present I see no need to add any of these to Java.
>> >>
>> >>
>> >>
>> >> On Sun, Nov 29, 2009 at 1:14 AM, Ken Bloom wrote:
>> >>>
>> >>> On Fri, 27 Nov 2009 08:48:28 -0500, Maxime Lévesque wrote:
>> >>>
>> >>> > Let's hope some do come out for 1.7.
>> >>> > Last time I checked, closures were not going to make it in 1.7, which
>> >>> > made me loose hope for the java language, fortunately Scala is there !
>> >>> > ;-)
>> >>>
>> >>>
>> >>> Last time you checked must have been before Mark Reinhold made his
>> >>> announcement at Devoxx last week that the time has come for Java to have
>> >>> closures (or at least lambdas). See his blog at http://blogs.sun.com/mr/
>> >>> entry/closures
>> >>>
>> >>> --
>> >>> Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
>> >>> Department of Computer Science. Illinois Institute of Technology.
>> >>> http://www.iit.edu/~kbloom1/
>> >>>
>> >>
>> >
>> >
>> >
>> > --
>> > Daniel C. Sobral
>> >
>> > I travel to the future all the time.
>> >
>>
>>
>>
>> --
>> Ricky Clarkson
>> Java and Scala Programmer, AD Holdings
>> +44 1565 770804
>> Skype: ricky_clarkson
>> Google Talk: ricky.clarkson@gmail.com
>> Google Wave: ricky.clarkson@googlewave.com
>
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>

On Sun, 2009-11-29 at 19:44 +0000, Ricky Clarkson wrote:
> A rule needs to exist, and it needs to be simple enough to follow for
> programmers concerned about unnecessary references.
>
> [I haven't checked what Scala does]

And whatever rule is used, it won't satisfy everyone:

https://lampsvn.epfl.ch/trac/scala/ticket/2617

But then again, that may be true of any feature. :)

Best,
Ismael

On Sun, 29 Nov 2009 19:44:42 +0000, Ricky Clarkson wrote:

> I'd say that it has closures but doesn't capture non-final local
> variables.
>
> There are garbage collection issues involved in capturing non-final
> locals. Consider:
>
> int x;
>
> Runnable a = #() { x++; };
> Runnable b = #() { x++; };
>
> return b;
>
> Should x be stored in the enclosing object (and hence the enclosing
> object would need a collection), in the first Runnable, a, or in the
> second Runnable, b? Whichever you choose could cause an object to live
> longer than it would if x was final. There may be an option I haven't
> thought of.
>
> A rule needs to exist, and it needs to be simple enough to follow for
> programmers concerned about unnecessary references.
>
> [I haven't checked what Scala does]

So Java developers will come up with the uglisest kludge, but it will
have the least problematic behavior in terms of unnecessary references
and object leaks:

final int[] x=new int[1];

Runnable a = #() { x[0]++; };
Runnable b = #() { x[0]++; };

return b;

Ultimately, the compiler should do this for the programmer.

2009/11/29 Ken Bloom :
> On Sun, 29 Nov 2009 19:44:42 +0000, Ricky Clarkson wrote:
>
>> I'd say that it has closures but doesn't capture non-final local
>> variables.
>>
>> There are garbage collection issues involved in capturing non-final
>> locals.  Consider:
>>
>> int x;
>>
>> Runnable a = #() { x++; };
>> Runnable b = #() { x++; };
>>
>> return b;
>>
>> Should x be stored in the enclosing object (and hence the enclosing
>> object would need a collection), in the first Runnable, a, or in the
>> second Runnable, b?  Whichever you choose could cause an object to live
>> longer than it would if x was final.  There may be an option I haven't
>> thought of.
>>
>> A rule needs to exist, and it needs to be simple enough to follow for
>> programmers concerned about unnecessary references.
>>
>> [I haven't checked what Scala does]
>
> So Java developers will come up with the uglisest kludge, but it will
> have the least problematic behavior in terms of unnecessary references
> and object leaks:

And, of course, not allowing concurrency to sneak in local variables.
Not unexpectedly, considering the millions Java programmers that are
going to be impacted, they decided to play it safe.

>
> final int[] x=new int[1];
>
> Runnable a = #() { x[0]++; };
> Runnable b = #() { x[0]++; };
>
> return b;
>
> Ultimately, the compiler should do this for the programmer.
>
>
>
>
>
> --
> Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
> Department of Computer Science. Illinois Institute of Technology.
> http://www.iit.edu/~kbloom1/
>
>

Ricky Clarkson
writes:

> A rule needs to exist, and it needs to be simple enough to follow for
> programmers concerned about unnecessary references.

C++0x explores this problem for its lambda functions, and allows the
function's argument list to specify whether to copy or capture a
variable from the environment by reference. However, for reference
bindings, it's the caller's responsibility to not invoke the function
after any of the referenced objects have gone out of scope. In that
sense, the closure is /not/ introducing "indefinite extent" as an
on-demand substitute for the normal "dynamic extent".

Ken Bloom wrote:
> So Java developers will come up with the uglisest kludge, but it will
> have the least problematic behavior in terms of unnecessary references
> and object leaks:
>
> final int[] x=new int[1];
>
> Runnable a = #() { x[0]++; };
> Runnable b = #() { x[0]++; };
>
> return b;
>
> Ultimately, the compiler should do this for the programmer.

From my experince this kind of kludge appears by two reasons:

1. an absence of tuples.
2. wrong approach to calculations.

First one have nothing in common with final/non-final question. There
should be touples.

Second one could be solved with replacing for/while/repeat with
fold/reduce/etc/.

Personaly I support final/nondestructive-binding variables.

My opinion that this is correct behaviour:

# let x = 5;;
# let f = fun y -> y + x;;
# f 10;;
- : int = 15
# let x = 10;;
# f 10;;
- : int = 15

And this is hell on earth:

>>> x = 5
>>> f = lambda y: x + y
>>> f(10)
15
>>> x = 10
>>> f(10)
20

Vladimir Kirichenko wrote:

> And this is hell on earth:

But I've found this hell very useful in javascript:))

Vladimir Kirichenko
writes:

> And this is hell on earth:
>
>>>> x = 5
>>>> f = lambda y: x + y
>>>> f(10)
> 15
>>>> x = 10
>>>> f(10)
> 20

Common Lisp allows that behavior by referencing special (free) variables
from the closure, or your earlier example by capturing objects directly.

First, the special variable version:

,----
| (defvar *x* 5)
|
| (defvar *f*
| (lambda (y)
| (+ *x* y)))
|
| (funcall *f* 10)
| > 15
|
| (let ((*x* 10))
| (funcall *f* 10))
| > 20
`----

Now, the captured variable version:

,----
| (defvar *f*
| (let ((x 5))
| (lambda (y)
| (+ x y))))
|
| (funcall *f* 10)
| > 15
| (let ((x 10))
| (funcall *f* 10))
| > 15
`----

Vladimir Kirichenko wrote:

Ken Bloom wrote:

> And if they had tuples, it would be

No it wont unless you really want it this way. This kind of kludge
(x[0]++) appears when there is an another result. For example:

#int(int) g = #(int z) { x[0]++; return f(z) };

With a presence of tuples it would be transformed to something like:

#T2(int) g = #(int z) { return (f(z), x+1) };

On Mon, 30 Nov 2009 23:31:46 +0200, Vladimir Kirichenko wrote:

> Ken Bloom wrote:
>
>> And if they had tuples, it would be
>
> No it wont unless you really want it this way. This kind of kludge
> (x[0]++) appears when there is an another result. For example:
>
> #int(int) g = #(int z) { x[0]++; return f(z) };
>
> With a presence of tuples it would be transformed to something like:
>
> #T2(int) g = #(int z) { return (f(z), x+1) };

Excuse me. I wasn't discussing the "proper functional way" to write this
code.

Most Java programmers use side effects without even thinking about it,
and tend to think of the lack of side-effects as a limitation that needs
to be circumvented in with kludges, not paradigm changes.

The array solution is what they'll come up with. They won't even bother
with the tuple solution even if that is available as a language feature.

--Ken