Angel Faus writes:
: Hi,
:
: I was reading Damian's new excellent diary entry in which he explains the
: new currying syntax for Perl6.
:
: (For the lazy ones it's reachable at
: http://www.yetanother.org/damian/diary_latest.html)
:
: This new feature allows to partially fill place-holder functions, such as:
:
: my &div = {$^x / $^y};
:
: my &half= &div(y=>2};
: print half(6); # 3
:
: This is a very neat feature, and very useful, as it's explained very well on
: Damian's page.
:
: But I am not sure I like the syntax. The problems I see are:
:
: - You only can curry placeholder-generated functions. So if you intend to
: make a function curryiable, you are forced to use place-holders, even if
: that's not the cleanest way of programming it.
I think that if you use an explicit signature, the declared variable
$^a is really just $a, so you wouldn't have to have arrows all over
the body of your function.
: - This means that the creator of a function needs to impose a policy on
: whether he expects the function users to use currying or not. A module
: creator and user could have different point of views about it, creating
: unnecessary conflict between the human race.
Well, yes, as I've been telling people (and as you point out below), we
need the policy anyway if we're going to support defaults. But yes,
there could certainly be difference of opinion between the creater and
the usor.
: - From the caller point of view, the only distinction between a function
: call and a currying pseudo-call, is the number of parameters.
:
: div(6,3) # is a function call
: div(6) # creates a new curryied function
:
: So, in order to see if a expression is a function call or a magic currying,
: you need to count (!) the number of parameters, without any visual clue
: suggesting it.
:
: - You cannot use advanced perl 6 features (like optional strict typing, or
: default values for function parameters), on curryiable functions.
There is the additional problem that you have a function returning a
completely different type (unrelated to its declared return type, if
any) depending on the argument count.
: I would instead propose that every function object supports a "curry"
: method, that performs such operation.
:
: For example:
:
: sub div($x,$y) {$x / $y}; # of &div = {$^x / $^y}
:
: my &half = &div.curry(y=>2);
: print half(6); # 3
:
: This solves the unnecessary placeholder-currying marriage, and it is
: certainly a more explicit syntax.
Yes, I've been wondering myself whether there ought to be some way
for the caller to override the prefs of the declaration with respect
to currying. Though it's possible that there's some overhead in making
any function curriable, since you essentially have to keep the original
template around in order to instantiantiate it whichever way. Imagine
if every function in C++ were really a generic on every parameter...
: Incidentally, a newbie user would learn that there is a curry method being
: called, and could google "curry perl" and even find some useful docs.
:
: (In my humble opinion, this is something that is too many times forgotten in
: the perl world. With the ultra-compact, idiomatic syntax, it is __very__
: hard to learn perl the google way).
I think that's a very valid point. I lucked out by naming Perl with
a word that wasn't a word. It's harder to search for Ruby.
: What do you think about it?
My one quibble with your proposal is that I think we still need
self-declaring, self-ordering parameters, and it could be argued that
if they exist they might as well curry automatically. Though perhaps
good style would dictate use of the curry method anyway. Certainly it
can also be argued that currying is not going to happen often enough in
stock Perl that it needs that ultimate in Huffman coding, the null
operator.
If we're going to make it a method, however, it's possible that "curry"
is the wrong popular name, despite its being the correct technical name.
There's really nothing about the word "curry" that suggest partial
binding to the casual reader. Perhaps we really want something like:
my &half = &div.prebind(y => 2);
or:
my &half = &div.rewrite(y => 2);
or even:
my &half = &div.assume(y => 2);
I think I like that last one the best. Maybe it would read better as
"assuming". But that's getting a bit long for Mr Huffman. Maybe it's
finally time to reach into our bag of English topicalizers and pull out
"with":
my &half = &div.with(y => 2);
Larry
