map and grep are the same way -- at first, they look like inscrutable shorthand for a two- or three-statement for loop...

I've still to see an example of when I might want to use this in Perl?

Tom kinda dismissed this, as my not being familar with the concept, so therefore I could see the opportunities, but I think he is wrong.

So far in this thread, I haven't seen anyone else come up with a good, everyday example of where currying would have done something useful.

I spent a good part of the last few days going through some of the 8000+ small scripts in my test directory looking for places where I might have used this. So far, not a single one.

Every place where I call a sub with constant value parameters in the first one or two positional arguments, the functions are in a loop so I only needed to type it once anyway.

All currying would have done in these situations is add an extra two (_c) or more characters to type in-line, plus the use Autocurry qw[ :all ] plus have to worry about making sure that I positioned that use line appropriately so that only the subs I wanted curried would follow it.

Every way I look at this, currying (or Autocurrying) buys me nothing. I have to type more. My code runs more slowly.

And with autocurrying, I have an extra administrative task of ensuring that the sequence and position of use lines relative to each other, and to my sub definitions is correct.

Normally, my use lines go at the top of the program in whatever order I realise I need them. Except when using threads when I have to be somewhat more careful to conserve space.

And I know exactly what a pain it is having to think about that, so the idea of having another set of position dependancies to worry about is a total anathema to me.

That maybe a part of the problem. Haskell programs have an entirely different structure to Perl programs.

Nope. No matter how hard I try, I cannot see any merit in currying, and especially not Autocurrying in Perl (5). None at all. I can never envisage it becoming anything beyond a mildly interesting curiosity.

In Perl 6, if the overhead of sub calls is less, and the syntax built in and more condusive to it's use, maybe it will become more prevalent, but I still don't see it ever becoming common, nevermind ubiquitous.

Time will tell :)

BrowserUk wrote:

So far in this thread, I haven't seen anyone else come up with a good, everyday example of where currying would have done something useful. I spent a good part of the last few days going through some of the 8000+ small scripts in my test directory looking for places where I might have used this. So far, not a single one.

You must understand that currying is a tool for functional programming. I don't find it surprising that you could look through any number of utterly un-functional, imperative programs and not see opportunities for using currying. In the desert, you won't see many opportunities for using a fishing pole, either.

(And, for the record, I regret ever trying to provide a non-FP motivating example for currying. It was dumb to show currying out of its most useful context.)

Perl is not a great language for functional programming. The coding cost of FP in Perl is too high to be practical. But that does not mean that FP isn't genuinely useful and powerful, and that also does not mean that Perl could not benefit from more FP.

What I, and some others, are trying to do is lower the cost of FP in Perl to the point where it becomes practical. Near-free currying is an important part of that process. If you look at real FP code, it is littered with currying. Almost everywhere you see function composition – probably the most common form of "glue" for joining functions in FP – you'll see currying.

For example, here are the first few functions from my Haskell-based entry in the most recent Programming Fun Challenge:

main               =  getArgs >>=
                      interact . readSolveAndShow . read . head

readSolveAndShow v
    | v >= 0       =  showSolution
                   .  flip findMinWinSoln v
                   .  readStateStats
    | otherwise    =  const "Please specify >= 0 target e-c votes\n"

readStateStats     =  map mkStatsEntry
                   .  groupsOf 3
                   .  map (filter isAlphaNum)
                   .  words
[download]

See those dots? That's the function composition operator. In real FP code, you'll see a lot of it. Its neighbors almost always involve currying. Here, currying is used four times in main, three times in readSolveAndShow, and five times in readStateStats. In fact, all three of those functions are nothing more than curried–function call pipelines.

The point of inexpensive curring isn't to make your imperative Perl code better. The point is to make FP practical in Perl.

All currying would have done in these situations is add an extra two (_c) or more characters to type in-line, plus the use Autocurry qw( :all ) plus have to worry about making sure that I positioned that use line appropriately so that only the subs I wanted curried would follow it.

I don't follow this logic. The _c notation requires fewer keystrokes than does the equivalent sub{}. If you only want a few, hand selected subs to support currying, just list them instead of :all in AutoCurry's import list.

And with autocurrying, I have an extra administrative task of ensuring that the sequence and position of use lines relative to each other, and to my sub definitions is correct.

AutoCurrying :all doesn't curry the modules you have used, only the namespace in which you used AutoCurry. Take another look at the implementation; I don't think it does what you think it does.

Nope. No matter how hard I try, I cannot see any merit in currying, ...

If you can't see any merit in currying at all, not even in FP, you are indeed missing something. This is not something over which the jury is still debating. Currying is immensely useful for FP. (Write a several-page chunk of FP code without using currying, and I'll show you how currying would make it better.)

... and especially not Autocurrying in Perl (5). None at all. I can never envisage it becoming anything beyond a mildly interesting curiosity.

Here you may be right. Perl 5 is a semi-hostile environment for FP (but not as hostile as most other popular languages). That's why Step One is making FP in Perl less expensive. AutoCurry is part of that. A library of tiny FP combinators is another part. MJD's new book will certainly help, too.

Maybe I am wasting my time. But, I can't help it: I love Perl. I love FP. And I would love to see them come together.

Time will tell :)

Indeed.

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.

Cheers,
Tom

Tom Moertel : Blog / Talks / CPAN / LectroTest / PXSL / Coffee / Movie Rating Decoder

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.

---

Examine what is said, not who speaks.

"But you should never overestimate the ingenuity of the sceptics to come up with a counter-argument." -Myles Allen
"Think for yourself!" - Abigail        "Time is a poor substitute for thought"--theorbtwo         "Efficiency is intelligent laziness." -David Dunham
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

... or Java (actually, I have my doubts about Java -- maybe you can make it work with anonymous classes)

No need for anonymous classes (yuk), you just need to use an alternate compiler, check out Pizza, it seems to not have been updated since 2002, but it's still a cool project.

That doesn't make it hard. That just makes it obscure.

Okay, i will go with you on that, with the one caveat that it for a large percentage of programmers out there it is not a simple concept to grasp, since the language they use (C/C++, Java, VB, etc) has no facility with which to do it. IMO, without a solid frame of reference it will likely not be very easy for them to grasp. But you are correct, that doesn't mean its hard (it just means those languages SUCK ;-).