Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #20867 > unrolled thread

Re: Why is that in JDK8: value used in lambda expression shuld be effectively final?

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? jeti789@web.de - 2013-01-02 07:08 -0800
    Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? jeti789@web.de - 2013-01-02 07:52 -0800
    Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Steven Simpson <ss@domain.invalid> - 2013-01-02 17:33 +0000
      Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Saxo <jeti789@web.de> - 2013-01-02 11:31 -0800
        Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Lew <lewbloch@gmail.com> - 2013-01-02 12:52 -0800
          Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-02 20:58 -0400
            Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Lew <lewbloch@gmail.com> - 2013-01-02 17:40 -0800
              Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-03 20:43 -0400
          Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Saxo <jeti789@web.de> - 2013-01-02 23:44 -0800
            Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Patricia Shanahan <pats@acm.org> - 2013-01-03 07:57 -0800
              Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Lew <lewbloch@gmail.com> - 2013-01-03 13:22 -0800
                Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Patricia Shanahan <pats@acm.org> - 2013-01-03 16:14 -0800
        Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Steven Simpson <ss@domain.invalid> - 2013-01-02 21:46 +0000
          Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Lew <lewbloch@gmail.com> - 2013-01-02 17:35 -0800
          Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Saxo <jeti789@web.de> - 2013-01-03 02:13 -0800
            Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Saxo <jeti789@web.de> - 2013-01-03 06:45 -0800
              Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Steven Simpson <ss@domain.invalid> - 2013-01-04 21:32 +0000
                Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-01-04 14:38 -0800
                  Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Steven Simpson <ss@domain.invalid> - 2013-01-04 23:45 +0000
                    Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-01-04 17:24 -0800
                      Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Steven Simpson <ss@domain.invalid> - 2013-01-05 13:20 +0000
                Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Saxo <jeti789@web.de> - 2013-01-05 01:50 -0800
                  Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Steven Simpson <ss@domain.invalid> - 2013-01-05 11:21 +0000
                    Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Saxo <jeti789@web.de> - 2013-01-05 04:27 -0800
                      Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Steven Simpson <ss@domain.invalid> - 2013-01-05 12:58 +0000

Page 1 of 2  [1] 2  Next page →

#20867 — Re: Why is that in JDK8: value used in lambda expression shuld be effectively final?

Hi Steven,

thanks for your elaborte answer.

>For some definition of closures (one including mutable local capture),
>JDK8 lambdas are not closures (hence, they are not called closures). 

I see, I didn't know. I wished Sun/Oracle had made this more clear ...
 
>AIUI, the main goal of lambdas was to reduce verbosity/overhead of
>anonymous classes used with algorithms that better exploit >parallelism. 

Well, JDK8 lambdas how they must be called then do at least reduce the amount of boilerplate code ...
 
Anyhow, this news does really put a smile on my face. Guess it's really time to look for another JVM-based language like Groovy or Scala ;-).

Regards, Oliver

[toc] | [next] | [standalone]

#20868

> Anyhow, this news does really put a smile on my face.

... does NOT put a smile on my face, of course. Guess this will give Groovy2.0 more momentum.

[toc] | [prev] | [next] | [standalone]

#20875

On 02/01/13 15:08, jeti789@web.de wrote:
> Anyhow, this news does [not] really put a smile on my face. Guess it's really time to look for another JVM-based language like Groovy or Scala ;-).

For your particular case:

   List<Integer> ints = ...;
   int sum = 0;
   ints.forEach(i -> { sum += i; });

...the recommended way is to use something like:

   int sum = ints.reduce(0, (x, y) -> x + y);

...which is more parallel-friendly.  Of course, if you don't care about 
the parallelism, it's simply:

   int sum = 0;
   for (int i : ints)
     sum += i;

I'm sure you're just using this example to explore what's available, and 
I think it would be a mistake to discard Java based on it.  So is there 
a more sophisticated case you were hoping would improve with lambdas?


-- 
ss at comp dot lancs dot ac dot uk

[toc] | [prev] | [next] | [standalone]

#20879

> I'm sure you're just using this example to explore what's available,

Yes, exactly. This little code snippet to calcualate a sum is a very simple but canonical case of a closure that has a free variable:

"When a function refers to a variable defined outside it, it's called a free variable. A function that refers to a free lexical variable is called a closure.". Paul Graham, ANSI Common Lisp, Prentice Hall, 1996, p.107.

So free variables aren't possible with JDK8 lambdas. For people used to closures, this is surely surprising. Well, this does not render JDK8 lambdas useless. On the contrary, an imense amount of boilerplate code that is necessary without them can be removed with them. Once the JDK8 gets released this will be an eye-opener to about 95% of all Java developers (the ratio of Java developers not understanding closures ...).

> I think it would be a mistake to discard Java based on it.

If I could I would have done that a long time ago. But not going with a M$ language was a deliberate decision and on the JVM nothing will rival Java (only be a complement like Groovy, or scratch on it like Scala or Kotlin). 

> int sum = ints.reduce(0, (x, y) -> x + y); 

Nice, but it does not compile with me. I use IDEA 12 and the lambda-8-b69-windows-i586-17_dec_2012 JDK. Seems like reduce does not exist in Iterator or Collection!?

-- Oliver

[toc] | [prev] | [next] | [standalone]

#20881

Saxo wrote:
> So free variables aren't possible with JDK8 lambdas. For people used to closures, this is surely 
> surprising. Well, this does not render JDK8 lambdas useless. On the contrary, an imense amount of 
> boilerplate code that is necessary without them can be removed with them. Once the JDK8 gets 
> released this will be an eye-opener to 
> about 95% of all Java developers (the ratio of Java developers not understanding closures ...).

The ratio of Java developers who do not understand closures is probably pretty close to the 
ratio of Java developers who do not understand Java.

Aside from that your comment is unsupportable. Or do you have evidence?

... 

I thought not.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#20889

On 01/02/2013 04:52 PM, Lew wrote:
> Saxo wrote:
>> So free variables aren't possible with JDK8 lambdas. For people used to closures, this is surely
>> surprising. Well, this does not render JDK8 lambdas useless. On the contrary, an imense amount of
>> boilerplate code that is necessary without them can be removed with them. Once the JDK8 gets
>> released this will be an eye-opener to
>> about 95% of all Java developers (the ratio of Java developers not understanding closures ...).
>
> The ratio of Java developers who do not understand closures is probably pretty close to the
> ratio of Java developers who do not understand Java.
[ SNIP ]

I don't get that statement at all. A significant percentage of Java 
programmers don't use any other languages in a big way, including those 
that do have closures. And since Java itself doesn't have them (*), I 
just don't see why a programmer who understand Java really well can't 
also *not* know about closures.

AHS

* I'll wager that a lot of Java programmers - the ones with their hands 
full still doing their production work in JDK 1.6 and 1.7, say, don't 
have time to play with experimental features.

[toc] | [prev] | [next] | [standalone]

#20894

Arved Sandstrom wrote:
> Lew wrote:
>> Saxo wrote:
>>> So free variables aren't possible with JDK8 lambdas. For people used to closures, this is surely
>>> surprising. Well, this does not render JDK8 lambdas useless. On the contrary, an imense amount of
>>> boilerplate code that is necessary without them can be removed with them. Once the JDK8 gets
>>> released this will be an eye-opener to
>>> about 95% of all Java developers (the ratio of Java developers not understanding closures ...).
> 
>> The ratio of Java developers who do not understand closures is probably pretty close to the
>> ratio of Java developers who do not understand Java.
> 
> [ SNIP ]

> 
> I don't get that statement at all. A significant percentage of Java 

You mean you don't agree with it. Apparently you do get it.

> programmers don't use any other languages in a big way, including those

How significant? What percentage? Aren't these the same ones I said don't understand 
Java either?

How do you know they aren't?

> that do have closures. And since Java itself doesn't have them (*), I 
> just don't see why a programmer who understand Java really well can't 
> also *not* know about closures.

Can, certainly. But the statement was statistical, not possibilistic.

Where does "95%" come from? Where does "significant percentage" come from?

My point is that there are no data for these assertions. Likewise, I have no data, but 
unless you do you have nothing with which to refute my assertion.

Plus there's the aforementioned matter of agreeing on definitions.
> 
> * I'll wager that a lot of Java programmers - the ones with their hands 

How much is "a lot"? Does it approach 95%?

> full still doing their production work in JDK 1.6 and 1.7, say, don't 
> have time to play with experimental features.

I have my hands full doing production work in JDK 1.6 and 1.7. Yet I do play with 
experimental features, and even read about them beyond that.

Doesn't everyone? Don't you?

Anyone who doesn't, doesn't understand Java.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#20936

On 01/02/2013 09:40 PM, Lew wrote:
> Arved Sandstrom wrote:
>> Lew wrote:
>>> Saxo wrote:
>>>> So free variables aren't possible with JDK8 lambdas. For people used to closures, this is surely
>>>> surprising. Well, this does not render JDK8 lambdas useless. On the contrary, an imense amount of
>>>> boilerplate code that is necessary without them can be removed with them. Once the JDK8 gets
>>>> released this will be an eye-opener to
>>>> about 95% of all Java developers (the ratio of Java developers not understanding closures ...).
>>
>>> The ratio of Java developers who do not understand closures is probably pretty close to the
>>> ratio of Java developers who do not understand Java.
>>
>> [ SNIP ]
>
>>
>> I don't get that statement at all. A significant percentage of Java
>
> You mean you don't agree with it. Apparently you do get it.
>
>> programmers don't use any other languages in a big way, including those
>
> How significant? What percentage? Aren't these the same ones I said don't understand
> Java either?
>
> How do you know they aren't?
>
>> that do have closures. And since Java itself doesn't have them (*), I
>> just don't see why a programmer who understand Java really well can't
>> also *not* know about closures.
>
> Can, certainly. But the statement was statistical, not possibilistic.
>
> Where does "95%" come from? Where does "significant percentage" come from?
>
> My point is that there are no data for these assertions. Likewise, I have no data, but
> unless you do you have nothing with which to refute my assertion.
>
> Plus there's the aforementioned matter of agreeing on definitions.
>>
>> * I'll wager that a lot of Java programmers - the ones with their hands
>
> How much is "a lot"? Does it approach 95%?
>
>> full still doing their production work in JDK 1.6 and 1.7, say, don't
>> have time to play with experimental features.
>
> I have my hands full doing production work in JDK 1.6 and 1.7. Yet I do play with
> experimental features, and even read about them beyond that.
>
> Doesn't everyone? Don't you?
>
> Anyone who doesn't, doesn't understand Java.
>
Well, we can agree on one thing - absent hard numbers - which I'm not 
sure exist - none of us have more than anecdotes.

I'll say this - I've worked closely with hundreds of programmers over my 
career. Not just Java, obviously, everything under the sun. I've 
interviewed many dozens of developers. I've seen a humungous amount of 
code written by other people. I read professionally voraciously.

These same statements are probably applicable to you and a bunch of 
other people in this NG too.

_My_ takeaway from all that is that most professional working 
programmers are M-F 9-5. They don't actually spend time at home coding 
or doing professional development (with the exception of training or 
reading books that help them with the immediate technologies that they 
need *now*). They don't have more than an above-average grasp of 
anything, they aren't even that interested in the field.

So no, I don't believe for a second that more than 5 or 10 percent of 
coders play with experimental features or learn languages that they may 
never use on the job...let alone teach themselves CS underpinnings of 
what they do.

But this is all anecdotal. You may have all your career worked with 
young hard-chargers who absolutely live to code. You'd see things 
differently.

As for *me*, the new _language_ features in Java 7 don't exactly take 
more than a few hours to read about and trial out in a simple test 
program. I spent rather more time investigating the new APIs in 7, so I 
know what's there and can plan to use it if appropriate.

As for what is coming out in 8, I could not care less. I really could 
not. I'm not using 8 yet, and none of my Java work (which these days is 
a small bit of what I do) will even be on the Java 8 platform for years. 
So why waste my time? I'd rather hone up on Scala, Clojure, latest C#, 
and F#...to name a few.

AHS

[toc] | [prev] | [next] | [standalone]

#20916

> Aside from that your comment is unsupportable. Or do you have evidence? 

What I mean is that almost every Java developer I met during the last 10 years didn't know what I meant when I said it's a pitty that Java does not have closures. I can't remember anyone who asked anything else in return than "and what are closures?". Having worked some of these years as a consultant I did see places. Almost nobody are those famous 95%. Funny that people get that annoyed. For the older guys that have worked with some other language than Java before the difference f.ex. between Smalltalk developers and Java developers is striking in terms of intellectual reflection, general interest, etc. Probably a good place to be nowadays is the people from the Scala camp. 

-- Oliver

[toc] | [prev] | [next] | [standalone]

#20923

On 1/3/2013 12:14 AM, Stefan Ram wrote:
> Saxo <jeti789@web.de> writes:
>> What I mean is that almost every Java developer I met during
>> the last 10 years didn't know what I meant when I said it's a
>> pitty that Java does not have closures.
>
>    Clojure already exists, and everyone who wants to program
>    the LISP style is free to choose LISP or Clojure.
>
>    Using LISP style in Java is not necessarily good Java style!
>
>    For a Java programmer, good knowledge of Java is already
>    sufficient. He does not need to know terminology of other
>    languages!
...

I would distinguish different levels of programming skill. If one is
going to be making decisions such as choosing the language for a
project, it is important to understand the capabilities and supported
programming styles for a wide variety of languages.

Similarly, anyone working in programming language design and
standardization should understand the possibilities that have been
demonstrated by other languages.

For someone who is just programming in one language, it is enough to
know that language well.

Patricia

[toc] | [prev] | [next] | [standalone]

#20930

Patricia Shanahan wrote:
> Stefan Ram wrote:
>> Saxo writes:
>>> What I mean is that almost every Java developer I met during
>>> the last 10 years didn't know what I meant when I said it's a
>>> pitty that Java does not have closures.

On this newsgroup there've been spirited discussions on this topic for years.

In my experience over the last ten years lots and lots of Java programmers, most 
of the ones with whom I've spoken, knew what closures were if they were reasonably 
competent Java programmers.

But I don't claim statistical significance for my non-random idiosyncratic sample. 
You should not either.

The fact that my experience is the opposite of yours should be evidence for that.

For the record, I argued vehemently against the addition of closures to Java. 

I tend to agree with Stefan here.

>>    Clojure already exists, and everyone who wants to program
>>    the LISP style is free to choose LISP or Clojure.
> 
>>    Using LISP style in Java is not necessarily good Java style!
> 
>>    For a Java programmer, good knowledge of Java is already
>>    sufficient. He does not need to know terminology of other
>>    languages!

Wrong.

> ...
> I would distinguish different levels of programming skill. If one is
> going to be making decisions such as choosing the language for a
> project, it is important to understand the capabilities and supported
> programming styles for a wide variety of languages.
> 
> Similarly, anyone working in programming language design and
> standardization should understand the possibilities that have been
> demonstrated by other languages.
> 
> For someone who is just programming in one language, it is enough to
> know that language well.

Wrong.

It is not enough.

Because people who learn only Java tend not to even program Java well.

That I've seen. I don't know if that has statistical significance.

But based on my experience and much reading and the advice of mentors, 
I will state unequivocally that knowledge of only Java makes a terrible computer 
programmer.

Simply terrible.

Any real programmer would have learned at *least* one other language, usually 
prior to learning Java, and would understand things like computable pointers.

Anyone who calls themselves a programmer and is unwilling to learn a second programming 
language is an ass and needs to switch to serving fries to fast-food customers.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#20935

On 1/3/2013 1:22 PM, Lew wrote:
...
> Any real programmer would have learned at *least* one other language, usually
> prior to learning Java, and would understand things like computable pointers.

Given its total emphasis on pointers, to the extent that they are the
only way to access a non-primitive, I doubt if anyone could know Java at
all well without having a deep understanding of pointers. I don't know
whether programming in other languages is the only way to get that
understanding.

Patricia

[toc] | [prev] | [next] | [standalone]

#20882

On 02/01/13 19:31, Saxo wrote:
>> int sum = ints.reduce(0, (x, y) -> x + y);
> Nice, but it does not compile with me. I use IDEA 12 and the lambda-8-b69-windows-i586-17_dec_2012 JDK. Seems like reduce does not exist in Iterator or Collection!?

I figured, if forEach is on Collection, reduce likely would be too. I 
did try to have a look for it in source, but wasn't sure if I had the 
right branch.  I also didn't find the javadoc on-line.  Based on the 
source, try:

   ints.stream().reduce(0, (x, y) -> x + y)

-- 
ss at comp dot lancs dot ac dot uk

[toc] | [prev] | [next] | [standalone]

#20893

Steven Simpson wrote:
> Saxo wrote:
>>> int sum = ints.reduce(0, (x, y) -> x + y);
> 
>> Nice, but it does not compile with me. I use IDEA 12 and the 
>> lambda-8-b69-windows-i586-17_dec_2012 JDK. Seems like reduce does not exist in 
>> Iterator or Collection!?
> 
> I figured, if forEach is on Collection, reduce likely would be too. I 

'forEach' is not on Collection. It's on Collection's parent type.

> did try to have a look for it in source, but wasn't sure if I had the 
> right branch.  I also didn't find the javadoc on-line.  Based on the 
> source, try:

Javadoc for Java 8 is on line:
http://download.java.net/jdk8/docs/api/index.html

Not hard to find, but it doesn't contain the information you wanted.


>    ints.stream().reduce(0, (x, y) -> x + y)

http://datumedge.blogspot.com/2012/06/java-8-lambdas.html
gives a brief overview.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#20920

Am Mittwoch, 2. Januar 2013 22:46:00 UTC+1 schrieb Steven Simpson:
>    ints.stream().reduce(0, (x, y) -> x + y)

This did it ;-). Thanks, good to know.

[toc] | [prev] | [next] | [standalone]

#20921

I wrote a little blog post about the matter to sum it up:

http://objectscape.blogspot.de/2013/01/jdk8-lambdas-as-restrictive-as.html

Hope it is enjoyable

[toc] | [prev] | [next] | [standalone]

#20955

On 03/01/13 14:45, Saxo wrote:
> http://objectscape.blogspot.de/2013/01/jdk8-lambdas-as-restrictive-as.html

I'm still interested in seeing an example that you would normally write 
with free variables, demonstrating that lambdas are inadequate for the 
things you'd like to do.  The example you provided of summing integers 
has two alternatives, so it only serves to show that free variables are 
not possible, not that free variables are necessary.

Can you contrive something more sophisticated, as an exercise?

-- 
ss at comp dot lancs dot ac dot uk

[toc] | [prev] | [next] | [standalone]

#20956

On Fri, 04 Jan 2013 21:32:38 +0000, Steven Simpson wrote:

> On 03/01/13 14:45, Saxo wrote:
>> http://objectscape.blogspot.de/2013/01/jdk8-lambdas-as-restrictive-as.html
> 
> I'm still interested in seeing an example that you would normally write 
> with free variables, demonstrating that lambdas are inadequate for the 
> things you'd like to do. [...]

I can't speak for the previous poster.  But clearly, closures don't do
anything you _can't_ do using lambdas or even using some other technique.

The point is convenience, expressiveness, readability, and other code
authoring and maintenance such as may be of concern are affected.  In the
view of closure proponents (such as my own), these concerns are addressed
in a positive way when closures are available.

In C# (for example), this basic approach (described in the language either
as anonymous methods or lambda expressions, depending on how exactly they
are actually written) results in the compiler generating a hidden class
that is used to store captured variables. Appropriate instances of the
hidden class are created with each instantiation of the lambda, to provide
storage for the captured variable.

Obviously, one can just do the same thing explicitly in Java.  For that
matter, even before lambdas in Java you could always accomplish the same
basic end result, just writing the code more explicitly.

But that's the point: lambdas, closures, etc. offer a more concise,
expressive way of representing certain algorithm approaches.  In this
context, I can confirm that there are plenty of examples of situations
where a true closure offers a more convenient, improved way of achieving
the same desired result, as compared to language syntax without closures.

Pete

p.s. Fair disclosure: I will also admit that true closures introduce new
ways of creating bugs in one's program.  In C# for example, there is some
confusion over when a new variable instances is created, leading to
programmers writing code where they either unintentionally share the same
captured variable amongst multiple closure instances, or they
unintentionally fail to do so when that's what they wanted, depending on
how/where the captured variable is declared.

Java's "final" requirements wrt anonymous classes and lambdas reduce
functionality in the language as compared to others (such as C#), but with
the benefit of it being harder to create erroneous code in the common case.

With great power comes great responsibility. :)

[toc] | [prev] | [next] | [standalone]

#20957

On 04/01/13 22:38, Peter Duniho wrote:
> I can't speak for the previous poster.  But clearly, closures don't do
> anything you _can't_ do using lambdas or even using some other technique.
>
> The point is convenience, expressiveness, readability, and other code
> authoring and maintenance such as may be of concern are affected.  In the
> view of closure proponents (such as my own), these concerns are addressed
> in a positive way when closures are available.

Indeed.  I'm interested in seeing how much expressiveness (etc) is lost 
when one is forced to work around the lack of a feature, by looking at 
specific cases.


> But that's the point: lambdas, closures, etc. offer a more concise,
> expressive way of representing certain algorithm approaches.  In this
> context, I can confirm that there are plenty of examples of situations
> where a true closure offers a more convenient, improved way of achieving
> the same desired result, as compared to language syntax without closures.


Do these examples fall into just a couple of categories, in terms of the 
guarantees that the user of a function object makes to the provider 
about how it will be invoked?:

 1. The object will be invoked on the same thread that provided it (e.g.
    in an event-driven environment)
 2. (1) + the object will not be invoked once the call that provided it
    has completed (e.g. in control abstraction)

...or are there more, especially ones which make fewer or alternative 
guarantees?

I'm genuinely interested to see if there are more categories.  Then, if 
they are limited, could a set of type qualifiers express these 
guarantees formally, and allow compilers to progressively switch on 
features like mutable local capture and various transparencies safely?

-- 
ss at comp dot lancs dot ac dot uk

[toc] | [prev] | [next] | [standalone]

#20964

On Fri, 04 Jan 2013 23:45:54 +0000, Steven Simpson wrote:

> [...]
> Do these examples fall into just a couple of categories, in terms of the 
> guarantees that the user of a function object makes to the provider 
> about how it will be invoked?:
> 
>  1. The object will be invoked on the same thread that provided it (e.g.
>     in an event-driven environment)
>  2. (1) + the object will not be invoked once the call that provided it
>     has completed (e.g. in control abstraction)
> 
> ...or are there more, especially ones which make fewer or alternative 
> guarantees?

Honestly, I'm not aware of a lambda/closure taxonomy that uses those
categories at all.  If such exists, I am ignorant of it.

First and foremost is that the "user of a function object" often has no
knowledge that a closure is being used at all.  It knows it's received a
function object of some sort (e.g. a delegate instance in C#/.NET), but the
origin of that object could be varied.

A given API may or may not make promises regarding usage of the function
object, but these promises likely have little to do with the declaration
and implementation of the function object.

Beyond that, wrt point #1: function objects, even those made from closures
with captured variables, may be safely invoked even in a multi-threaded
environment, so long as the code is written correctly.  For example,
enforcing volatile or fully-synchronized access to shared variables
(whether due to capturing or otherwise).

Wrt point #2: because variable capturing involves effectively "lifting" the
variable out of the declaring method's local context, invoking the function
object after the declaring method has completed is not a concern at all.
Captured variables aren't stored in the stack frame, specifically because
there are no lifetime guarantees otherwise.  The captured variable's
lifetime is modified so that rather than existing for the duration of the
method call, it exists for the duration of the closure that uses it.

> I'm genuinely interested to see if there are more categories.  Then, if 
> they are limited, could a set of type qualifiers express these 
> guarantees formally, and allow compilers to progressively switch on 
> features like mutable local capture and various transparencies safely?

Such features can be enabled even without such declarations, as happens in
C#.  Such declarations are more likely to pertain to compiler
optimizations, rather than specific capturing features.

The hazards in using captured variables in C# closures don't exist because
of the issues you've raised (well, not #2 for sure...#1 may or may not come
up, but is not a closure-specific issue anyway), but rather more often it's
a problem of the programmer comprehending when a closure is sharing a
variable instance with other closure instances and when it's not.

The programmer does have control, via how the captured local variable is
declared, as to whether each closure's instance of the variable is shared
with other closure instances made from the same code expression.  But they
do have to make sure they declare the captured variable correctly for their
needs, and doing so can be a bit of a challenge for programmers new to
closures.

(I should note that that last paragraph is entirely from a C# perspective.
It's possible, likely even, that at least some other languages don't have
the same "gotcha".  For example, a language without mutable variables at
all would obviously not require the programmer to concern themselves with
whether a variable instance is shared or not).

Pete

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web