BrowserUk, thanks for your detailed response. You obviously invested serious time in it, and I will do my best to give you an adequate "return" with my comments below.

First, I think that you have a fundamental misunderstanding of how functional programmers use currying. In order to see it, we must must distinguish between partial application and currying. In common usage, they are often used interchangeably, but let's be clear now: Partial application is the process of applying a function to a portion of its arguments to yield a new, specialized function. Currying is one way to implement partial application.

Now to focus on the misunderstanding, let's examine this comment:

But that's my point. [The use of currying] in Haskell (and others) is so fundamental, that i[t] "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.

On the contrary, the Haskell programmer must always know exactly when he wants to partially apply a function. Like a programmer for any other language, he must understand the nature and expectations of the functions he calls and know when he is or is not supplying all of their arguments. The Haskell programmer uses partial application purposefully, carefully, and with clear knowledge of the fact that he is doing it.

To be clear, Haskell programmers do not think, "I am going to use currying on this call to function f." Nor do they think, "I do not know how many arguments this function takes, so I will just pass in what I have, and if it is not enough, currying will save the day." Rather, they think, "Here, I am going to apply f partially to yield a new, specialized function."

The exact same burden is placed upon a Perl programmer wanting to use partial application. However, because Perl does not support partial application natively, the Perl programmer is at a slight syntactical disadvantage: Whereas the Haskell programmer can partially apply a function by knowingly passing in fewer arguments than the function takes (at which point currying takes over), the Perl programmer must do the same but also use additional syntax in order to trigger the partial application (at which point a homebrew partial-application system takes over).

The mental burdens placed upon Haskell and Perl programmers are identical when it comes to partial application. Only in keystrokes is there a difference.

Now, please let me skip a large part of your text that follows from the above logic and jump to your point 2:

However, currying isn't (just) a useful, elegant, feature of FP, it is also a necessity.

Please understand that your assessment of currying's necessity for FP is incorrect. The Scheme language, for example, does not have language-level support for partial application, and yet it is one of the most popular FP languages in use today. Partial-application support (e.g., currying) merely lowers the cost of FP by making certain common operations more convenient. It is a convenience, not a necessity.

Likewise, your assessments of the costs of AutoCurry are off because you are measuring the cost of the wrong thing:

Administration: Which functions do I curry?

As I hope I communicated earlier, the mental cost of using currying (or any kind of partial-application support) is not the cost of considering which functions to curry but rather which function calls you want to be partial applications. The cost is the same, regardless of how you implement partial application: You must understand the function that you are calling, and you must understand what subset of its arguments you want to specialize on by binding now, in order to yield a new function that expects the remaining arguments later.

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

Your assessments of elegance and usefulness use imperative-style programming as the measuring stick. As I said in my previous reply, that is like assessing the elegance and usefulness of a fishing pole by taking it to the desert. If you want to understand the elegance and usefulness of a fishing pole, take it to the water and use it to catch fish. Likewise, if you want to measure the elegance and usefulness of a Perl-based partial application system, use it to write some FP code.

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.

Thank you for keeping an open mind. I think you'll have better luck in reaching meaningful conclusions if you keep these points in mind:

1. Don't focus on currying. Focus on partial application, which is what counts.
2. Currying is just one way to implement partial application.
3. AutoCurry is another way to implement partial application, one that happens to work well for Perl. (As I have argued elsewhere, I do not think that real currying is a good fit for Perl (5)).
4. If you want to understand the merits of being able to perform partial applications, write FP code – don't think in terms of imperative-style coding.

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.