Sorry for the delay on getting back to you Tom; I was off reading. Though you may regret my ever getting back to you once you've read this :) (I hope that's a joke!)

When I wrote:

Nope. No matter how hard I try, I cannot see any merit in currying, and especially not Autocurrying , in Perl (5).

I omitted a comma (indicated above), which (I think) changes the meaning of the sentence such that you quoted the sentence and responded to it in two halves.

I do see the merit in currying--in Haskell and other FP langauges. It is a fundamental part of those languages, and of their underlying philosophy and implementations.

Indeed, it would be (pretty much?) impossible to write a Haskell program that didn,t use currying--transparently and ubiquitously.

But that's my point. It's use in Haskell (and others) is so fundamental, that is "just happens". The Haskell programmer has no need to think about which functions he should curry, when he should curry them, or how to do the currying. He just composes those functions he requires, in the appropriate order, from the other functions who's outputs, are the inputs the new function needs, using the usual syntaxes, and if a function needs currying, it is done.

At no point in the process does he have to think:

"When I come to use this function, I won't (may not) have all the arguments available to me, so therefore I better curry it now with this or that partial set of arguments, so that the curried version is available when I need it later."

To be able to use currying (or autocurrying) in Perl(5), that s exactly the type of foresight and decision that the programmer would need to make.

From here on down, I'm walking on dodgy ground. I'm going to speak like I understand (some) of Haskell, which is a flawed assumption at this stage, but it's the only way I can express what I'm trying say. Please make allowances

Haskell's transparent currying has some nice side-effects. When constructing your program, you can start top-down and if at some point in the definition of the program you discover that you need a value that will be obtained or derived from a function that you haven't coded yet. No problem.

Invent a name for that function and use it. Provided you have at least one of it's parameters available now on which to later trigger the currying of the rest, then Haskell will ignore that the full function is not yet defined, and allow you to fill in the blanks in a later definition. The compile-time pattern matching process will take care of making the appropriate connections between this partial function use and a corresponding later definition that matches it.

That is a very powerful concept. In some ways it is remenicient of the Prolog style of doing things. Except, if I remember my long distant flirtation wth Prolog, it would quite happily go ahead and start running your code (often for hours as I recall :), before belatedly discovering that it didn't actually have a rule to cover a situation that could arise. That absence of "compile time completeness checking" is one reason (IMO) that Prolog never made it as a mainstream language. If I have understood any of this, I think that Haskell would detect whether you have used a partial function pattern for which you had not provided an appropriate definition, pretty early. Ie. When it attempts to make the appropriate bindings at "compile time"?

And that, I think, is the problem I see with using currying in P5. It doesn't allow you to use a function for which it has no prior knowledge. (Method calls aside.)

Perl also doesn't have any mechanism for performing pattern matching (in the namespace sense of that term--otherwise known in OO (principally C++) circles as name-mangling). This means that it is pretty impossible to automate the process of currying, other than through presumptive positional criteria. That's further exacerbated by Perl's allowing variable numbers of arguments to functions (as you mentioned), combined with the "typeless" nature of Perl's arguments. Every parameter is a scalar--and a scalar can be (quite literally) anything.

Indeed, it is Perl's total absence of a formal argument binding mechanism, typeless (more generously termed polymorphic) scalar parameters, that force you to encode the types of the curried parameters into the function names. You are, in effect, having to do the pattern matching or name mangling yourself.

Automating this process (in P5) would be really quite hard to get right, as you would have to effectively replicate the P6 signatures and muiltimethods concepts. And the only real option for doing that would be to do runtime discovery of parameters through the likes of can, ref and isa. A rather messy, and expensive, runtime cost.

In fact, TheDamian has already released a module for performing Perl6::Currying, along with a supporting module, Perl6::Placeholders. As a source filter it may not be to everyones taste, but that does allow some or all of the work in performing the pattern matching to be confined to compile-time rather than run-time.

Even there, the examples are of the halve(); double(); treble(); type, which allows me to say:

## $left = 0; $right = 10;
my $mid = halve( $left + $right ); ## $mid = 5
## And maybe?
my @mids = halve( @left zip @right ); ## ?
[download]

instead of

my $mid = ( $left + $right ) / 2;
my @mids = zip{ ( $_[ 0 ] + $_[ 1 ] ) / 2 } @left, @right;
[download]

The value of which eludes me? As, taken to it's ultimate conclusion, I'd also need definitions for:

add_1( ... );
add_2( ... );
add_3( ... );
add_4( ... );
...
## And
quarter( ... );
eigth( ... );
sixteenth( ... );
...
three_quarters( ... );
seven_sixteenths( ... );
...
x_div_3_123_456_789_000( ... );
x_div_3_123_456_789_001( ... );
x_div_3_123_456_789_001_point_1( ... );
...
[download]

!?

So, whilst I criticised your original Perlish example, I also praised your attempt to find one that was non-trivial.

To summarise:

1. I do see the effectiveness of using currying in Haskell (and FP languages in general).

   However, currying isn't (just) a useful, elegant, feature of FP, it is also a necessity. Whilst I'm always in favour in making a virtue of a necessity--in context.

   Perl (5 or 6), does not have that necessity.

   As such, the only things that adding the feature to the language would bring with it is are the "useful" and "elegant" factors.

   The elegance in Haskell is, in large part, due to it's transparancy, which is completely undone if I have to manually do the currying. Even with the Autocurrying you offered, the programmer still has to decide what, and when to curry. And so, the elegance factor goes out of the window to a very great extent.

   In addition, it imposes it own costs in in terms of

   • Administration: Which functions do I curry?
   • Performance: Extra levels of subroutine nesting exact a fairly high performance penalty in Perl 5.
   • Namespace pollution: Every curried function adds a new name to the namespace.
   • And every namespace where it is curried.
   • >And for every variation of parameters for which it is curried?
2. I do not see the benefit of currying (or autocurrying) in Perl 5.

   In the absence of necessity and elegance, and bearing the costs in mind, that leaves the possibility of "useful".

   I dont think that it is an unreasonable stance for my to be looking for a "useful" use of currying. So far, I haven't seen that.

   The only useful possibility muted to this point is the Tk callback scenario. That is, replacing

    
       $stopped = 1;
       my $stop = sub { $stopped = 1 if shift() };
       ...
   
       $game->command(
            -label => '~Stop', 
            -command => $stop,
            -accelerator => 's'
       );
   [download]
   

   with (something like):

   Autocurry qw[ stop ];
   ...
       $stopped = 1;
       sub stop { $stopped = 1 if shift() };
       ...
   
       $game->command(
            -label => '~Stop', 
            -command => stop_c(),
            -accelerator => 's'
       );
   [download]
   

   Which is a bad example, but the best I found. The problems I see are:

   • whilst the name in the first example is tightly scoped, the name of the currying function in the second is not.
   • whether the currying function will generate the appropriate closure over the $stopped variable?
   • I would be forced to name all the functions that I want to curry on the use Autocurry qw[ ... ]; line to avoid producing currying functions for every other function in the namespace following it.
   • That last item introduces another cost. That of maintaining the names in two places.
3. Perl 6 will have the underlying mechanisms and methods required to make currying possible and reasonably efficient.

   However, from my reading of Apo 6, and Syn.6-Currying, it will still be very much a manual process rather than transparent and pervasive, which somewhat dilutes it's ease of use relative to Haskell et al.

   Even the examples in Synopsis 6 leave me with more questions than answers at this point:

      &textfrom := &substr.assuming(str=>$text, len=>Inf);
   [download]
   

   [SNIP]

   It returns a reference to a subroutine that implements the same behaviour as the original subroutine, but has the values passed to .assuming already bound to the corresponding parameters:

       $all  = $textfrom(0);   # same as: $all  = substr($text,0,Inf);
       $some = $textfrom(50);  # same as: $some = substr($text,50,Inf);
       $last = $textfrom(-1);  # same as: $last = substr($text,-1,Inf);
   [download]
   

   These include, but are not necessarially limited to:

   1. What is the scope of &textfrom?

      Lexical? Package? Can the programmer decide?

   2. Is the binding of str=>$text lexical, package, global?

      Presumably, that depends upon the scoping of the bound variable?

   3. What happens if the curried function definition has a wider scope than that of the variable over which it is bound?

      Is that possible?

   4. Finally, the utility (apparently) comes from the keystroke saving.

      Only having to type $textfrom( 50 ), rather than  substr( $text, 50 ). (I assuming that the missing 3rd parameter will retain it's P5 default "the rest" semantics).

      However, to achive that saving, I've had to type:

         &textfrom := &substr.assuming(str=>$text, len=>Inf);
      [download]
      

      which by my count means that I am going to have to use $textfrom( nn ) instead of substr( $text, nn ) at least 12 times (in the appropriate scope), in order to realise that utility. I cannot find a single example of a piece of code where I (or anyone else) has used substr this many times in at the same level of scope, such that the currying would realise a benefit.

      The nearest thing I found was Erudil's How to (ab)use substr, with 15 uses of substr. But if you look carefully at that, you'll see that only 11 of them would be candidates for currying of the first parameter--which fails to meet the requirements of saving keystrokes. In anycase, that is a very rare example. Anytime a Perl programmer has to call a function with one or more of the parameters as constants, it is almost always done in a loop.

      And that's another reason why FP uses currying, but Perl doesn't.

      That's besides the fact that I am going to have to go and look up the names of all the arguments to the function I am currying.

      Quick! Without looking back up, is that first parameter called:

      1. String?
      2. Or string?
      3. Or Str?
      4. Or Text?
      5. Or text?
      6. Or 1st?
      7. And what about the second parameters name?

      That last one made you look didn't it? Even if the others didn't. And even though it isn't necessary to know it (and isn't mentioned). For this example!

   5. If I rename the variable $text in the above example, should I rename the curried function also?
4. Efficiency.

   From doing what I can to try and understand the discussion and code surrounding (what I belive is) the underlying technology--continuations--in Parrot that will enable currying for languages that use it, I've some concernes regarding the effect that their provision will have upon the performance of the languages.

   But that's a discussion for a different place and time, and one which I am even less qualified to address than this one.

5. Too many more questions arise for me to (continue to?) bore you with. This "summary" is already aproaching the length of the post above it! So I'll shut up--real soon now :)

Thanks for taking the time to put your doubts in writing. That takes guts, especially when you're sitting in the FP-cheerleading part of the stadium.

Trying not to sound too much like a Hollywood awards ceremony;

Thanking you, for recognising that my writings are indeed expressions of my doubts, and my attempts to resolve them. Not any pronouncement of "the way it is" or definitive conclusion. When I reach a conclusion on a subject, I rarely join in discussion of it; unless I see something that causes me to question my conclusions.

On this subject, I have not yet reached any conclusions. I have my leanings, which are probably fairly evident by now, but there are also enough indicators that I am leaning the wrong way for me to know that I still need to keep an open mind and do a lot more reading and experimentation on the subject.