|There's more than one way to do things|
Re^8: Near-free function currying in Perlby FoxtrotUniform (Prior)
|on Nov 18, 2004 at 08:13 UTC||Need Help??|
I guess my point really is that currying is something which is not to be used lightly. It is, by its very nature, an advanced technique which is not easily accessible or understandable to most programmers who were trained in procedural or OO programming.
I'm sorry, I have to disagree.
I don't think that currying's a particularly advanced technique, or a particularly difficult one to grok. I do think that currying in particular, and "functional programming techniques" in general, have gotten a reputation for being difficult to understand, and that programmers approach them expecting difficulty... and creating that difficulty if they don't find it.
One thing that really threw me when I was learning Haskell was the fact that most partial expressions are perfectly valid... they just return functions that (given the right arguments) complete the expression. That's not an example of currying being difficult, although currying is the mechanism I'm talking about: it's an example of Haskell doing something that most languages do not (that is, transparently currying everything). Currying is just a matter of caching an argument.
A well crafted Haskell or Standard ML function will be built with the understanding, that it will almost certainly be curried at some point. Old perl code will almost certainly not be built with the same considerations. That is not to say that you shouldn't still use currying in those situtations, but I think it ill advised to imply that currying can breath new life into old code.
I don't understand. None of the curry functions I've seen on PM does anything more than wrap the curried function in a closure that remembers what the curried argument was. I guess functions that make heavy use of caller or other recondite corners of Perl's introspection might break when curried, but that's about it. I can't think of any "plain old subroutine" convention that would break when curried. I think that most existing code would survive currying quite happily, though I'm willing to speculate that not everything would.