On Tue, 14 Sep 2004, Larry Wall wrote: > : So what I would like to do is (i) C<map> the list of templates to a list > : of curried closures in which the first parameter is fixed to each given > : template, (ii) C<reduce> this list by means of right pipe binop > : ( C<< ==> >> ) with a "starting value" (leftmost) of, say, @input. > > It probably depends on just how we implement infix:==>. Looking for > a righthand argument that is curried to have all of its arguments > except for a list is one way to look at it. But all our currying so > far is explicit, and ==> in some sense wants to auto-curry its right > side to return some function with a missing list, even if it isn't > written that way, which means it's perhaps acting more like a macro > than a first-class function. But just because the actual binary ==>
Well, then maybe ==> is not the right infix operator. Mathematically one has the binary associative operation of "composition". Will Perl6 provide such an operator? It seems that ==> (or <== for a more "traditional" approach) could not be the right one since *in this context* it would pass its right argument to its left one, and not the output of the former as wanted ()... Also, mathematically, if one has a function of, say, two variables, f : A x B -> C it's common to indicate the function obtained by fixing one, say the first, of them by f(a,-) : B -> C So similarly Perl may support a similar syntax by means of suitable "placeholder variables" (obviously in a different sense than the already existing one!) > arguments of each ==> autocurry their own righthand arguments. I suspect > there's a way to write it, since we defined the splat list as just a > funky named parameter. Probably something like > > my $result = > (@input ==> > reduce &operator:==>, > map { &*pack.assuming(:template($_)) }, @templates > ); So it seems that currying will be allowed only on named parameters, won't it?!? Well, I guess this won't matter much here, but I've the *impression* that Perl6 rich parameter passing mechanism will be *too* powerful (to be flexible enough). > Mind you, I wouldn't write such code anywhere I expected anyone with > less than a PhD to stumble across, even if I ain't got one myself. Well I do *not* have a PhD myself, but it seems I have an inclination for functional languages-like constructs. And maybe I'm simply a strange guy, but a solution along the lines of that quoted above would be the most clear satisfying for me, for it makes obvious what is done in turn: (i) the list of templates is mapped to a list of functions, (ii) this list is reduce()d by means of composition of functions, (iii) the resulting function is evalutated on @input. And there's been no need to introduce or use intermediate variables (apart the "default one", $_). Michele -- > [are there] Any areas of mathematical knowledge or skills that we lost? Yes, but I don't remember what they are. - Kevin Foltinek on sci.math [edited]