any all each

[jonathandavid]

My current thinking is that a generator form would come via LINQ which kicks off with "from":

names = from p in persons where p.age > 18 yield p.name

# in C# that's
var names = from p in persons where p.age > 18 select p.name;

I'm glad you brought it up though because your example gives the idea that "yield" is a better keyword than "select" since there is already a "yield" keyword and using it is informative. So maybe we could kick off the query with "for" anyway as you suggested.

Well I just used "for" because that's what's currently used in list comprehensions, not because I think it's superior to "from". With respect to select/yield, I do think that "yield" would be more informative, but maybe it's better to keep LINQ compatibility anyway. I'm not too familiar with LINQ, does its specification incorporate the distinction between "create a list with all the elements" (Python's list comprehension) and "return one element at at time" (generator expression)? If it doesn't, then I think we could indeed have a modified version of LINQ in which "select x" returns a list with all the elements, and "yield x" produces them one by one.

[Charles]

LINQ queries do not immediately produce lists. They are lazy and generate their results when actually needed.

[jonathandavid]

LINQ queries do not immediately produce lists. They are lazy and generate their results when actually needed.

Thanks for clarifying this. So then I think the best approach is stick with "for foo in bar get foo" if we want a list generated, and resort to pure LINQ if we want laziness. No need for "for foo in bar yield foo" then.

Maybe, for the sake of consistency, it would have been desirable to make the list comprehension more "LINQ-like":

names = from p in persons where p.age > 18 <span style="font-weight: bold">add</span> p.name

Notice how I've made up the operator "add" to indicate that this LINQ-like expression adds each element that pass the filter to a list, instead of lazily generating it.