Skip to content

iteration library and lightweight bind syntax #1649

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

Closed
nikomatsakis opened this issue Jan 24, 2012 · 7 comments
Closed

iteration library and lightweight bind syntax #1649

nikomatsakis opened this issue Jan 24, 2012 · 7 comments
Assignees
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) C-enhancement Category: An issue proposing an enhancement or a PR with one.
Milestone

Comments

@nikomatsakis
Copy link
Contributor

I am working on a nicer iteration library. This requires a lightweight bind syntax. I am working on that too. You can see current status and get a flavor from the cargo package "iter", though the eventual plan is to move that into libcore (or libstd?)

The bind extension is that the bind keyword will no longer be required. So one can write foo(a, b, _) which means precisely the same thing as bind foo(a, b, _) used to, except that I plan to infer whether to use a boxed closure, stack closure, etc. It will also work for receivers, like _.foo(_). The plan is to have the code path in the compiler be very similar to the one used for closures (trans_bind, for example, should go away completely).

@ghost ghost assigned nikomatsakis Jan 24, 2012
@graydon
Copy link
Contributor

graydon commented Jan 27, 2012

Hm. Might make parsing a bit sneaky, but if you can make it work I'm not opposed.

@nikomatsakis
Copy link
Contributor Author

One issue occurred to me. This is not so much related to the parsing as it is related to my efforts to make bind() and closures follow the same path through the code (right now, bind is different, and hence many things that should work actually don't, e.g., bind v.foo(_)).

The change is that if I write foo(a, _) (here I will use bind-less syntax to indicate the new path through the code), then what I am generating is basically sugar for {|b| foo(a, b)}. But this is not the same as what bind foo(a, _) generated, which was kind of sugar for {let a0 = a; {|b| foo(a0, b)}}.

It's not clear to me that it's a problem, but it's a change. It has some advantages. It allows the syntax to work with movable values, for example, in particular stack closures. That means something like:

list.map({|x| x+2}, _) 

works just fine even if {|x| x+2} becomes a stack closure.

The disadvantage of course is that complex expressions get re-evaluated each time the closure is invoked.

@marijnh
Copy link
Contributor

marijnh commented Feb 2, 2012

This is a great idea. I've been talking about getting rid of the bind keyword in favour of such syntax for ages, but never actually did it.

@nikomatsakis
Copy link
Contributor Author

As a side effect, this fixes an existing bug in bind, which is that it ignored typestate predicates that were attached to the bound function.

@graydon
Copy link
Contributor

graydon commented Feb 15, 2012

I'm ok with such changes. You've done some of this already though, yes?

@graydon
Copy link
Contributor

graydon commented Mar 28, 2012

Further work on this is blocked on traits and regions, so bumping to 0.3.

@nikomatsakis
Copy link
Contributor Author

iter trait approach is basically there, though traits are needed to make it nice.

celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
* No longer use variables for locating the action.

* Modified path.

* Turned off action check until image is released to public.

This will fail with permissions issue until then.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

3 participants