Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

Re^14: Near-free function currying in Perl

by tmoertel (Chaplain)
on Nov 22, 2004 at 04:46 UTC ( #409484=note: print w/replies, xml ) Need Help??

in reply to Re^13: Near-free function currying in Perl
in thread Near-free function currying in Perl

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.


  • Comment on Re^14: Near-free function currying in Perl

Replies are listed 'Best First'.
Re^15: Near-free function currying in Perl
by BrowserUk (Pope) on Nov 22, 2004 at 07:05 UTC

    I did warn you that I was going to talk as if I understoof FP :) Thanks for making allowances and not making capital from that gross misassumption.

    I remember when I first tried to learn SmallTalk. I was trying to get to grips with it at home whilst continuing to write hardcore C + assembler(device drivers) for 10 hours a day at work. I never quite "got" SmallTalk until I was commisioned to write a "First Introduction" course, and got to spend a month completely immersed in the language. Only then did the penny drop. It's still my all-time favorite language, although I have considerable reservations about it's use for commercial, multi-programmer projects.

    It seems obvious that in order to get the usefulness of FP, I will need to spend a similar amount of time, or more, completely immersed in Haskell or one of the other modern implementations of FP. That is going to be a hard thing to pursuade myself to do. I have several ongoing projects in Perl and D that I want to bring to a close first.

    **This is (mostly) a joke**.

    A like your Fishing Pole analogy--a lot--but both times you brought it up, I couldn't help myself wondering why I (you) would want to use Perl to write FP?

    I guess I will need to reach the point where writing code in the FP style no longer seems an "unnatural practice" before I will be able to answer that question.

    When I do try to do something in Haskell, I still find myself having to spend a ratio of like 10 or 20 to 1 reading the docs and example code to time actually coding. I keep wanting to use loops, conditionals and temporary variables and insert a few prints to debug the code when it just sits there and does nothing. I started playing around with the famously elegant Haskell definition of the QuickSort algorithm. Neat, but is it ever slow and inefficient.

    So thanks for your articles and the time you've taken responding to my questions and doubts. I'll shut up now and let you get on with your explorations of FP in Perl unhindered.

    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
      Let me answer this question:
      A like your Fishing Pole analogy--a lot--but both times you brought it up, I couldn't help myself wondering why I (you) would want to use Perl to write FP?
      I want to be able to write FP-style code in Perl because it gives me more options for solving problems.

      I don't want to make Perl the next great FP language. All I want is to reduce the cost of FP in Perl so that I have the option to use FP when it's the best way to solve a problem.


        I've hoped you would respond with some examples of how you would use this in your own code. Could you show us examples with and without it? Or at least highlight what would be different?

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://409484]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (8)
As of 2019-06-19 14:01 GMT
Find Nodes?
    Voting Booth?
    Is there a future for codeless software?

    Results (88 votes). Check out past polls.

    • (Sep 10, 2018 at 22:53 UTC) Welcome new users!