On 16/05/2011 8:13 AM, john skaller wrote:
Sure just look at "binder1" and "binder2" in the C++ standard library and
wonder where "binder3" and "binder4" have gone. They haven't gone,
they're not defined. You need an infinite number of them. If you have only
one argument functions .. you only need one of them for completeness.
Here we're getting into (almost) a concrete argument. But I think you're
overdoing it.
binder1st and binder2nd are the only ones defined for a simple reason:
they cover all (or most) cases. Seeing why takes a momentary digression.
In any conversation about polymorphism, I think there are two very
different social cases you want to address:
(A) you wrote datatype X and function F and want to use some generic
like tree[X] or hashmap[K,X] and want to map/fold/process F
over the generic using higher order programming. Fine. Since you
wrote both X and F, you make sure F has a single domain/range,
be it a scalar, a record, or a tuple -- rust has those too -- and
you're done. You wrote both so you have control over args. F is
always 1-arg, and plays nice with your higher order fns.
(B) Serendipity. You are already working with a container of type
(say) tree[(a,b,c,d,e)] and you wish to munge the tree through
some independently written function of 5 args -- a function you
did not write and have no control over -- and then you realize
you can save yourself time by munging the 5-tuple through the
5-arg function using tree::fold. But oh! Only if the 5-arg
function is written to take a 5-tuple, not 5 separate args.
I *think* I am hearing you argue that this sub-case of B is what you're
worried about. That we have to always encode 5-arg functions as taking
5-tuples so that serendipity can have its day and you can reuse
tree::fold on 5-tuples and independently-written 5-arg functions.
My counterargument is simple and it's what I meant above by binder2nd
covering all cases: the odds against an *independently written* 5-arg
function taking the exact same 5 args (not 4, not 6, and not 5 in some
other order) are ... low. That as N increases from 1 the odds against a
serendipitous match between any two N-ary functions and argument tuples
matching up decreases geometrically. So much so that beyond "binary
function" is just never even *happens*, serendipitously, in the field.
This is why, I think, most FP toolkits max out at map2 and don't bother
writing a map3, map4, map5 and such. You'd only have a match between a
5-arg function and a randomly chosen 5-tuple if you wrote both the
function and the typedef. And then, yes, you'd just write your functions
as taking 1 arg (a tuple, a record, whatever) as you say. But that's not
a serendipity case, and it's easy to make work manually (or at worst
with the occasional adaptor function).
Am I misunderstanding?
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
