Currying in Python
mtomassoli.wordpress.com
mtomassoli.wordpress.com
edit: ° should've been * but I couldn't escape it without using spaces.
To reduce clutter and unobscure the point, and support uncurried usage (like apply(f, args) however that is done in Python) , it needs more lambdas instead, of defs:
f = lambda a: lambda b: f_uncurried(a, b)Python 2 has an apply function [1], but it was deprecated for a long time and removed in 3.0 [2]. apply(f, args) is equivalent to f(*args) in Python.
[1] http://docs.python.org/library/functions.html#apply
[2] http://docs.python.org/release/3.0.1/whatsnew/3.0.html#built...
currying is really really easy and everyday python programmers probably do it on accident.
def divisible(n, x): return n % x == 0
def divisors(n):
possible_divisors = range(2, int(sqrt(n))+1)
return filter(lambda x: divisible(n, x), possible_divisors) # OMG curry !
assert divisors(24) == [2, 3, 4]Currying isn't a big deal for python programmers. The article fails precisely because it makes currying into a big deal.
This is yet another example of how haskell got it wrong. Currying isn't something that one should do all the time or think about, so basing a language on it is dumb. (And that's true even if we ignore the complications that it adds to polymorphism.)
Can you elaborate on what you mean by this? As it stands I don't understand what this means.
> (And that's true even if we ignore the complications that it adds to polymorphism.)
Please elaborate on this as well.
Simon Peyton-Jones (haskell creator) often says in videos that haskell is a sandbox for playing with CS ideas that haven't yet mainstreamed. Monads are a great example - haskell's purity helped distill the idea into something less opaque and now these ideas are starting to pop up in mainstream languages - "jquery is a monad"[1].
its not haskell that is dumb, dumb is when people try to use haskell for things it wasn't designed for. Scala and Clojure are both chock full of functional opinions yet designed to be practical.
[1] http://importantshock.wordpress.com/2009/01/18/jquery-is-a-m...
I wasn't trying to imply that currying is a big deal for most Python programmers, nor do I agree that the article was. But I think it's probably safe to say that many Python programmers aren't familiar with it or how it can be effectively put to use, since in Python, it's a neat, occasionally useful technique, but isn't exactly "central" to the language. For whatever reason, Python also tends to attract a lot of beginner programmers, who probably haven't had enough experience to be exposed to functional techniques. I interpreted the article as targeting that kind of audience.
This is yet another example of how haskell got it wrong. Currying isn't something that one should do all the time or think about, so basing a language on it is dumb. (And that's true even if we ignore the complications that it adds to polymorphism.)
Disclaimer: I like Haskell a lot, so you should probably take my opinion with a grain of salt. I'm not trying to start an argument, just expressing a counter-opinion.
From my point of view, Haskell's "currying by default" approach gives you what is essentially a superset of the functionality available in most other languages, while taking away very little. It's fine to think of `f a b c` in Haskell as being equivalent to `f(a, b, c)` in Python, even though we know that, under the hood, f isn't really a function of 3 arguments. It has the same behavior as the Python version if you always fully apply it to all 3 arguments, though (ignoring strictness). But of course, Haskell conveniently allows you to partially apply f without requiring any extra effort on your part. At least Python gives you the functools library module to make that sort of thing easier; most languages don't even do that.
What does automatic currying take away? Well, as you alluded, function polymorphism based on the length of the argument list isn't as straightforward as it is in, say, Java, since Haskell functions really only have a single argument, period. But if you really want the ability to do this kind of overloading, it can be accomplished using type classes. And Python's optional/keyword arguments can be emulated using record syntax. It's just not particularly common to use these techniques, because most of the time there are much more idiomatic ways of accomplishing the things you might use function overloading for in a different language.
I'd be interested to hear what else you think is lost as a result of automatic currying. It's difficult for me to come up with anything other than benefits, but maybe I am being blinded by my enthusiasm for the language.
How about I use one of your examples.
> It's fine to think of `f a b c` in Haskell as being equivalent to `f(a, b, c)` in Python, even though we know that, under the hood, f isn't really a function of 3 arguments.
All abstractions leak. The fact that Haskell is always curried means that you always have to be aware of currying.
There are many kinds of problem solving. One is "how do I solve {x} using {y} in some clever way." Haskell is great for those folk. Another is "How do I solve {x}."
Here's one way to distinguish these two groups. The first sends "look at my cute solution to {x}" to their friends while the latter say they send "look at what I built".
To put it another way, when a user community is dominated by folks who write papers/essays about the tools, you've got a tool for folks who want to play with tools.
Haskell is wonderful for a subset of those folks who care a lot about tools, specifically those folks who think that mathematical purity is important.
There are other goals.
No, you don't. That was my point.
By pretending that functions aren't curried, you're limiting yourself to a subset of the language's full expressiveness, but it is a completely consistent subset; it behaves precisely as you would expect it to in the absence of currying. And that subset is equivalent to the expressiveness of Python (or any other language) without currying.
It sounds like you're implying that Haskell is just an odd assortment of academic "cute tricks" for impressing people who have nothing more important to spend their time on, and that any practical programmer would steer clear of it in order to "get things done". Frankly, this is the opinion of someone who has little experience with the language, or with functional programming in general. There are many ideas in Haskell which are unusual, or of seemingly little value to someone with a strictly imperative background. But as anyone who has used the language to build something practical can tell you, these "tricks" are much more than clever mathematical toys; they enable you to express your intent more succintly and with greater precision than with the tools provided by most other languages, with strong compile-time guarantees of correctness to boot. You tend to miss them quite a bit when using languages which lack these features.
Not everyone who uses Haskell falls in love with it, and there are plenty of arguments to be made both for and against the language, but your dismissive characterization is just naive.
Not at all. It's a very elegant system which attracts folks who really want to think about tools. That's not surprising, since that's what Simon Peyton-Jones (haskell creator) designed it for.
Anyway, I apologize for misinterpreting your tone.
Though, it's slightly off on the initial presentation of currying. Currying is the act of transforming a function that takes multiple arguments into a function that returns a function that takes n-1 arguments, and so on, not an "incremental binding of function arguments".
The issue of whether the caller has to explicitly call "partial" seems to be the meaningful distinction.