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]
