On 2/4/12 5:55 PM, Niko Matsakis wrote:
Anyway, I am happy to update my patch to make `_` be currying (as both
you and graydon preferred).
I think I spoke too soon about being happy. =)
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. I may go ahead and make the current `bind` parse without the
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.
I was thinking I might prefer to just have the iter library essentially
take a "manual currying" approach, where `map()` is not defined like so:
fn map<A,IA:iterable<A>,B>(self: IA, map_fn: fn(A) -> B, consume_fn:
fn(B)) {
self.iter {|a| consume_fn(map_fn(a)) }
}
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)) }
}
}
I didn't want to do this before because it's less efficient in some
cases, and a nice bind syntax would obviate the need. But it'd be easier
to implement and, in the common case, prettier to use (no underscores at
all):
something.do_filter {|t| ... }.do_map {|t| ... }.do {|t| ... }
In any case, I am wondering a bit about the design of the library. I'd
like to keep the "deforested by default" approach, but perhaps change
the API a bit to allow hints to be passed down about the eventual size
of the data structure. It'd be nice if the vector could be pre-allocated
to the right size, basically. Anyway, I hope to toy around with this a
bit today in parallel with CCI work.
Niko
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
