ACCEPTABLE?: List Comprehensions?

[Reinier Zwitserloot]

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