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

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.