Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re^9: Near-free function currying in Perl

by stvn (Monsignor)
on Nov 18, 2004 at 14:05 UTC ( #408767=note: print w/replies, xml ) Need Help??


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

For an advanced student of computer science, I would say currying is a simple concept. I would even say that for a not-so-advanced student of computer science who has been made to sit through a couple Scheme-based classes, currying is not an advanced concept. But many CS students I have meet have been trained in either C/C++ or Java and for them the idea of currying is very foreign. In C/C++ to do it would surely be an advanced usage of the language (if it is even possible), and currying in Java is impossible (unless you are using the Pizza compiler, but thats not Java and certainly not for CS 101).

And lets not forget that many programmers didn't go to school for CS (me amoung them). I highly doubt you are going to find the topic of curried subroutines anywhere in a MIS cirriculum, nor are you likely to find it in an Elec. Eng. progam. Many a EE and MIS grad go on to be programmers/developers. IMO functional programming in general is still a largely acedemic CS territory. Although as time goes by I am seeing what I would describe as a slow-leak of functional thought into the mainstream (OO/procedural) programming world, which I think is a very good thing.

As for how curry-able old crufty perl subroutines are. The more I thought about it, the more I think I put my foot in my mouth there. There are of course some odd cases where things will go awry, but thinking of modules like Memoize (which in many ways does things similar to currying) I can see that it would likely work out better than I initally thought.

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

Replies are listed 'Best First'.
Re^10: Near-free function currying in Perl
by FoxtrotUniform (Prior) on Nov 18, 2004 at 19:55 UTC
    IMO functional programming in general is still a largely acedemic CS territory.

    There's the rub. Yes, currying is largely academic. Sure, you can't do it in C or C++ or Java (actually, I have my doubts about Java -- maybe you can make it work with anonymous classes).

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

    map and grep are the same way -- at first, they look like inscrutable shorthand for a two- or three-statement for loop, but they're basically straightforward. You don't have to know a lot of theory to use map, or fundamentally change your outlook on programming. I think currying will turn out the same way.

    --
    Yours in pedantry,
    F o x t r o t U n i f o r m

    "Anything you put in comments is not tested and easily goes out of date." -- tye

      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 :)


      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
        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
        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

      ... 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 ;-).

      -stvn

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (2)
As of 2019-06-17 04:34 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Is there a future for codeless software?



    Results (76 votes). Check out past polls.

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