Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What should the behavour of map and collect be? #75

Closed
oxinabox opened this issue Oct 14, 2019 · 2 comments · Fixed by #81
Closed

What should the behavour of map and collect be? #75

oxinabox opened this issue Oct 14, 2019 · 2 comments · Fixed by #81

Comments

@oxinabox
Copy link
Member

it is a more contentious feature ...

If you believe map & collected generators ought not to simply propagate names along, then perhaps open a discussion issue?

Originally posted by @mcabbott in #73 (comment)

@mcabbott
Copy link
Collaborator

OK, my take is that all of these ought to propagate names:

A = [f(x) for x in nda]
B = map(f, nda)
C = [g(x,y) for x in nda, y in ndb]  # (names(nda)..., names(ndb)...)
D = map(g, nda, ndb)                 # unify(names(nda), names(ndb))
E = filter(h, nda)

Only some of them do now. What's the argument against any of these? Or what other cases need to be worried about before fixing them?

@oxinabox
Copy link
Member Author

oxinabox commented Oct 30, 2019

I am coming around to the the idea.
map(f, ::Tuple)::Tuple) afterall.

And also recently @glennmoy had code that would have benifited from this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants