On 04/02/2012 7:58 AM, Niko Matsakis wrote:
Hello,
As some of you have no doubt seen, in #1649 [1] I proposed a
lighterweight bind syntax which (basically) omits the keyword bind. Here
is the proposal:
https://github.com/mozilla/rust/wiki/Proposal-for-bindless-bind
I would paste it inline below but I think it's much easier to read
online, due to the formatting. There are several open-ish questions at
the end and I would appreciate your thoughts, as well as an overall "yay
or nay" opinion.
I'm mostly ok with this; answers to your issues follow:
1. I'm ok with binding on operators, yeah. We've lacked a good way to
easily denote op+ and such for a while, and _+_ fits nicely in our
syntax. Might get difficult to infer the overload though. Tread lightly.
2. This one is, I think, not OK. It's effectively changing a bunch of
expressions from call-by-value to non-memoizing call-by-need due to a _
in the neighbourhood. That's too hazardous. IOW I think it needs to remain:
f(a.b, _) => { let x = a.b; {|y| f(x,y) } }
The counterargument you put forth is "consolidated code path", but ... I
don't think that's sufficient justification. For constants it makes no
difference, but for mutable values and expressions with side effects it
makes a big, scary difference.
Bind is a notation borrowed from Sather, incidentally, and it binds by
value. Even if you want to look to more-mainstream languages for
precedent, you would look to the capture rules for lambda and currying.
Both of those, in most reasonable languages, capture values rather than
expressions (or variables). Indeed, the "closures from for-loops close
over the variable not the value" problem was being discussed as a major
js and C# anti-feature on #rust the other day. I don't think it's right
to be capturing un-evaluated expressions like this.
3. I don't entirely understand the concern, and I'm not sure it still
stands if you do what I'm requesting in #2 anyways, so going to defer.
Maybe we can talk more in person or on IRC :)
4. It's not too magical. The only major thing this proposal involves is
kicking out the `bind` keyword and generalizing the notation to hit
expression-positions we didn't previously know how to bind. So, 'bind'
already had a bug open for binding self in method calls, and I think
people had at least mentioned binding operators before (or auto-currying
them when quoted a certain way). Sather supported binding more things
than our 'bind' does presently anyways:
http://www.icsi.berkeley.edu/~sather/faq.html#17
So ... I'm ok with expanding its reach. I'm also ok with just kicking it
out altogether, since we have Real Lambdas now. It's redundant sugar,
one way or another, given environment capture.
I have little opinion on keeping or removing the keyword, if bind of any
sort survives. Rust started very keyword-y (due to my aesthetic
preferences, modeled on Napier88, Alef and Sather) but there has been
virtually unanimous, steady pressure to eliminate keywords from everyone
else I show it to, and it's hard to keep up such an argument
indefinitely. I am clearly in the same aesthetic minority here as with
my taste for for Boston City Hall.
-Graydon
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
