generator expressions are desugared to list comprehensions and range returns a list

[amtriathlon]

This is not semantically correct, in my own implementation these were desugared to iterator classes and that code would be rather easy to incorporate after the scope-rewrite merge, if there is consensus.

range should also produce an iterator class without eagerly generating a list.

[anandology]

I desugared that into chain of map and reduce calls. It wasn't that hard.

Also, list comprehensions can be desugared into list(generator-expression).

Anand

On Tue, Feb 19, 2013 at 8:42 PM, Alejandro Martinez < notifications@github.com> wrote:

This is not semantically correct, in my own implementation these were desugared to iterator classes and that code would be rather easy to incorporate after the scope-rewrite merge, if there is consensus.

— Reply to this email directly or view it on GitHubhttps://github.com/brownplt/lambda-py/issues/43.

Anand http://anandology.com/

[mpmilano]

Shouldn't they be desugared to generators I we are going through the effort of incorporating them anyway?

On Tuesday, February 19, 2013, Alejandro Martinez wrote:

This is not semantically correct, in my own implementation these were desugared to iterator classes and that code would be rather easy to incorporate after the scope-rewrite merge, if there is consensus.

— Reply to this email directly or view it on GitHubhttps://github.com/brownplt/lambda-py/issues/43.

[jpolitz]

Do they need the laziness/restarting behavior of generators to have the right semantics? If so, we should use generators. Otherwise, it seems like an iterator class would be fine.

On Tue, Feb 19, 2013 at 10:23 AM, xlnagla notifications@github.com wrote:

Shouldn't they be desugared to generators I we are going through the effort of incorporating them anyway?

On Tuesday, February 19, 2013, Alejandro Martinez wrote:

This is not semantically correct, in my own implementation these were desugared to iterator classes and that code would be rather easy to incorporate after the scope-rewrite merge, if there is consensus.

— Reply to this email directly or view it on GitHub< https://github.com/brownplt/lambda-py/issues/43>.

— Reply to this email directly or view it on GitHubhttps://github.com/brownplt/lambda-py/issues/43#issuecomment-13777783.

[amtriathlon]

They are required to be iterators (to implement the iterators protocol: next and iter) and generators produce iterators, so probably would be better to use them, but I don't think they are required just for generator expressions.

2013/2/19 Joe Politz notifications@github.com

Do they need the laziness/restarting behavior of generators to have the right semantics? If so, we should use generators. Otherwise, it seems like an iterator class would be fine.

On Tue, Feb 19, 2013 at 10:23 AM, xlnagla notifications@github.com wrote:

Shouldn't they be desugared to generators I we are going through the effort of incorporating them anyway?

On Tuesday, February 19, 2013, Alejandro Martinez wrote:

This is not semantically correct, in my own implementation these were desugared to iterator classes and that code would be rather easy to incorporate after the scope-rewrite merge, if there is consensus.

— Reply to this email directly or view it on GitHub< https://github.com/brownplt/lambda-py/issues/43>.

— Reply to this email directly or view it on GitHub< https://github.com/brownplt/lambda-py/issues/43#issuecomment-13777783>.

— Reply to this email directly or view it on GitHubhttps://github.com/brownplt/lambda-py/issues/43#issuecomment-13778671.

Alejandro.

[amtriathlon]

With map and reduce giving iterators this is another possibility.

BTW, we need to change the list constructor to accept any iterable as argument for the second part to work, currently it calls list on the parameter.

2013/2/19 Anand Chitipothu notifications@github.com

I desugared that into chain of map and reduce calls. It wasn't that hard.

Also, list comprehensions can be desugared into list(generator-expression).

Anand

On Tue, Feb 19, 2013 at 8:42 PM, Alejandro Martinez < notifications@github.com> wrote:

This is not semantically correct, in my own implementation these were desugared to iterator classes and that code would be rather easy to incorporate after the scope-rewrite merge, if there is consensus.

— Reply to this email directly or view it on GitHub< https://github.com/brownplt/lambda-py/issues/43>.

Anand http://anandology.com/

— Reply to this email directly or view it on GitHubhttps://github.com/brownplt/lambda-py/issues/43#issuecomment-13777764.

Alejandro.

[amtriathlon]

range also eagerly build a list instead of returning an iterator class, I added this to the issue and changed the category from enhancement to bug.

[amtriathlon]

Now we have generators, would be nice to use them to have a "proper" implementation of generator expressions which doesn't to convert them to list comprehensions! (even worst, without filter predicate (#42)

[jpolitz]

Indeed, I think this is worth having on the short list of things to do today and tomorrow.

On Mon, Mar 25, 2013 at 9:39 AM, Alejandro Martinez < notifications@github.com> wrote:

Now we have generators, would be nice to use them to have a "proper" implementation of generator expressions which doesn't to convert them to list comprehensions! (even worst, without filter predicate (#42https://github.com/brownplt/lambda-py/issues/42 )

— Reply to this email directly or view it on GitHubhttps://github.com/brownplt/lambda-py/issues/43#issuecomment-15393397 .