List comprehensions

[Lawrence Kesteloot]

Reinier Zwitserloot wrote:
> list comprehensions, /IF/ they produce a complete list and not a
> lazily evaluating iterable, is just syntax sugar.

In my proposal (http://docs.google.com/View?docid=d4tx2hw_46fkz8x6gt)
it's lazy /and/ syntactic sugar, but it requires that variables (other
than the source iterable) be final, as you said in a different post.
This is slightly inconvenient, but I wouldn't introduce all the
problems of closures just to deal with that.

I agree that immediately evaluating the list is easier and safer all
around. Rémi Forax made a similar observation on the kijaro mailing
list. I can't exactly remember why I didn't do that. I think I was
influenced by Python's drift towards making everything streams. I had
also recently read SICP, which pushes for stream computation. And
perhaps I wasn't sure which implementation of List to use. Also there
are some cases where it's more efficient; see the examples in the spec
that are based on SICP and FCM examples.

It wouldn't take you long to try your immediate-eval idea. Copy the
listcomprehensions branch of kijaro. The parsing is already done for
you, and the desugaring code would just get massively simpler. (The
current implementation must generate two nested classes to create an
Iterable that returns an Iterator.) I'd be happy to help you if you
get stuck.

In fact your new code would look a lot like the foreach desugar. It'd
be pretty simple, and I'm surprised that Joe thinks it's out of scope
for Coin. It's smaller than many of the other ideas.

Lawrence Kesteloot