On 2/6/2012 10:07 AM, Niko Matsakis wrote:
I've been thinking about the patch some more and I am not sure how I
feel about `_` being currying. This is not because I'm opposed to a
currying semantics as opposed to a closure semantics—though I'm not sure
that it's really better—but because I don't yet see how to implement it
well.
Ok. I hate to be a stick in the mud about this but part of what made
'bind' appeal to me initially was exactly that it encouraged the
formation of closures that were less-coupled to their environment than
those formed from function literals. The values got bound, never the
variables. I guess I was over-eager about this decoupling, but I still
really prefer to err on the side of decoupled behaviors by default.
Capturing a mutable variable someone else might mutate at a distance is
exactly the sort of footgun I prefer be non-default behavior in rust.
The sort of thing you have to mean-to-say to have it happen.
(I often express my preferences here in terms of balancing
expressiveness of some desirable results against anti-expressiveness of
undesirable results, like notational-ambiguity or module-coupling. IOW
trying to balance the ease of expressing meaning-X in the language with
defense against accidentally expressing anything _beyond_ meaning-X.)
keyword `bind`, since that seems universally popular, but that doesn't
actually address the implementation problems I was trying to address
(you can't bind methods, nor receivers, nor other expressions). The
problem is that addressing those with currying semantics will be more
invasive and I just don't want to spend the time on it right now.
Ok.
but rather like so:
fn map<A,IA:iterable<A>,B>(self: IA, map_fn: fn(A) -> B) -> fn@(fn(B)) {
fn@(map_fn: fn(B)) {
self.iter {|a| consume_fn(map_fn(a)) }
}
}
Yeah, that might well work better. Iter is a real pressure-cooker for
these features. It's exciting to see you bouncing around in this design
space, and I'd expect several passes of (re-)design. Keep notes on what
goes wrong each time, if you can! At very least keep posting updates on
what-works / what-doesn't to the list so we can follow along and
refer-back in the future :)
(We do not universally do this, much to our own loss.)
-Graydon
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
