ACCEPTABLE?: List Comprehensions? (original) (raw)

Reinier Zwitserloot reinier at zwitserloot.com
Mon Mar 23 11:33:27 PDT 2009

Kevin: The C# yield keyword does the exact same thing as was proposed
for java - it creates an inner class. This is what was meant by: Adds
all the intricacies of closures: Variables have to be final, and any
attempts to throw an exception inside such a construct all of a sudden
is no longer allowed (because the pseudo-interface you're implementing
doesn't allow it either - and more specifically, because you could
hand off your iterable and an entirely different code block could be
throwing them). This is very confusing if you don't understand the
intricacies of anonymous inner classes. At least actual anonymous
inner classes have a very specific syntax which allows someone not
familiar with them to read up.

Trying to solve these problems gives you about as much difficulty as
the various closure proposals floating around. Certainly doable, but
not within the scope of project coin.

Hence my suggestion to add them as a non-lazy list generator, which
avoids all of those problems. We can always add a lazy form later,
with the same syntax but for one minor difference (E.g. by employing
different brackets or adding a context sensitive keyword or some such).

--Reinier Zwitserloot

On Mar 23, 2009, at 19:11, Kevin Krouse wrote:

Joseph D. Darcy wrote:

Reinier Zwitserloot wrote:

Ah, list comprehensions. I forgot them on my list. They aren't closures, but you can do quite a few closure use-cases with them, and are a lot easier to understand. The draft proposal looks good (but is incomplete; it doesn't mention any JLS chapters, for example), but there's one big issue it doesn't mention: If the list comprehensions return Iterables, then the generating expression, as well as the filter expressions, are effectively 'closures' and get all the complications that stem from this. For example, you would not be able to use non-final variables in there, unless we change the rules regarding usage of non-finals in 'closures', which involves a significant change for the JVM (it has to declare that variable on the heap and not on the stack).

Generating the entire list on the spot has none of those issues, and turns the entire proposal into syntactic sugar + a new utility class in the spirit of Collections and Arrays, named 'Iterables'. That's all. Joe: If a list comprehension proposal is written that involves (extensive) syntax sugar + 1 new class file and nothing else, would they have a chance?

I would be doubtful such a change would be within scope. -Joe Is it too large for coin because of the syntax changes? Would something more like C# yield return/break be more acceptable since it looks more like a plain 'ol Java method? See Raymond Chen's explanation of the transformation performed for yield which doesn't require final variables or closures: http://blogs.msdn.com/oldnewthing/archive/2008/08/12/8849519.aspx To me, it seems on the same level of size as the JDK 5 for-each loop which was considered a small change. Kevin

More information about the coin-dev mailing list