List comprehensions (original) (raw)

Lawrence Kesteloot lk at teamten.com
Sat Mar 21 23:41:36 PDT 2009

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

More information about the coin-dev mailing list