On Sat, 18 May 2002, Angel Faus wrote:
> ...curry example...
> 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 never read that. It seemed to me like you could curry just about any 
function you please.

> - 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.

Very true. This is a mega-gotcha that should somehow be dealt with. In 
classic Perl, it would warn you about not enough arguments, but in Perl6 
it generates a curried function call? So I could say:

  print foo(2,3);

And if foo was in fact expecting three arguments and I was just 
brain-farting it would print some serialization of this? Or what? This 
doesn't make a lot of sense.

> - You cannot use advanced perl 6 features (like optional strict typing, or
> default values for function parameters), on curryiable functions.

Good point.

> 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.

I like it. Initially I was thinking a new "curry" operator (hmm... &$@! 
perhaps? :), but I think we're just about out of characters for that. 
Plus, with Perl6's OO design, C<.curry> fits well. 

Perhaps if it's generated with placeholders, the C<.curry> would be 
implicit. That way we can stay terse when the situation is simple. Like 
with Damian's C<given>...C<when> example.  When I'm writing scripts, I 
don't  want to type those 6 characters, but if I'm doing structured 
programming, the clearer the better. To parallel this, when I'm writing 
scripts, I'm going to use placeholder functions, but in structured 
programming, I'm probably not.


Luke

Reply via email to