ACCEPTABLE?: List Comprehensions?

[Reinier Zwitserloot]

If you copy the variables, then change them later, people are going to  
be rightly confused about why the comprehension still appears to read  
an old version.

Also, that still does not solve the checked exceptions issue, either.  
Its possible there's an easy answer here, but considering that  
everyone and their dog has submitted a closure proposal of some  
flavour or other, I kind of doubt there is one.

  --Reinier Zwitserloot



On Mar 23, 2009, at 20:57, Kevin Krouse wrote:

> I may have read the generated code wrong, but doesn't the C#  
> translated source just copy the method parameters and locals to the  
> generated class?  Only member fields referenced by the method need  
> to be final, right?
>
> Kevin
>
> Reinier Zwitserloot wrote:
>>
>> 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
>>