ACCEPTABLE?: List Comprehensions?
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).
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,
>>> are a lot easier to understand. The draft proposal looks good (but
>>> 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
>>> 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
>>> 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
>>> 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.
> 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.
More information about the coin-dev