Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re^12: Near-free function currying in Perl

by tmoertel (Chaplain)
on Nov 19, 2004 at 05:20 UTC ( #408944=note: print w/replies, xml ) Need Help??


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

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

Replies are listed 'Best First'.
Re^13: Near-free function currying in Perl
by BrowserUk (Pope) on Nov 20, 2004 at 08:58 UTC

    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 ); ## ?

    instead of

    my $mid = ( $left + $right ) / 2; my @mids = zip{ ( $_[ 0 ] + $_[ 1 ] ) / 2 } @left, @right;

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

    !?

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

      with (something like):

      Autocurry qw[ stop ]; ... $stopped = 1; sub stop { $stopped = 1 if shift() }; ... $game->command( -label => '~Stop', -command => stop_c(), -accelerator => 's' );

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

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

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

        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
      Currying in Perl 6 is not about saving keystrokes. It's about preserving abstraction, in the sense of letting you factor out those parts of an interface you're not interested in. For that reason, I expect curried modules and classes to be more heavily used than curried functions.

      It's also a bit of future proofing. I can pull in a module or function and use it all over the place in my program. Then suppose the author of that module or function decides to add an additional optional parameter that happens to default the "wrong" way. I can override that bad default with a single curry, even if they added that bad parameter to every function in the module.

      But we're not going to do implicit currying because we don't want the return type of a function to magically change just because someone tweaked the interface with an optional parameter or generalized one of the parameter types.

      Doubtless there will be a way to implement implicit currying if you really want it, but it won't be the default.

        Thanks. There are at least two, if not three, good uses for currying in a non-FP language in there.

        And, FWIW, I really like the name .assuming for the triggering method.

        As always when you step in a with such enlightenments, my brain goes into immediate overdrive thinking about the possibilities.


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

        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

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (5)
As of 2019-10-20 06:31 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?