Currying
wiki.haskell.org
wiki.haskell.org
splitString :: { pattern :: String, string :: String } -> Array String
splitString { pattern, string } = ...
splitString :: Pattern -> String -> Array String
splitString pattern string = ...Number.parseInt('10', 0) Number.parseInt('10', 1) Number.parseInt('10', 2)
JavaScript lacks typing, and then they decided on a weird signature for the callback...
It's a very nasty issue to debug.
It would look like this
newtype Radix = Radix { radixToWord :: Word }
newtype Index = Index { indexToWord :: Word }
Method calls are easier to read and work better with autocomplete.
Currying is a subset of partial application, so I suspect the person you're responding to is just being a bit loose with their wording, as opposed to not understanding the topic.
Some languages provide partial application without currying a function - JavaScript has bind, Python has functools.partial etc.
Language is inherently imprecise and communication is never perfect. When people say something, it's rude to assume they are wrong or don't understand something because they don't say it exactly the way you would have said it. This is extremely common in technical communication and it's extremely counterproductive.
I'm suggesting that you could be a better reader by trying to understand what people are trying to say even if they don't communicate it exactly the way you want them to.
For example, no one in this comment chain is confused about what currying or partial application are, so it's a bit rude that you've assumed people are confused because you didn't take the time to figure out what people were trying to communicate. Instead, because people didn't say things exactly the way you would have said it, you jumped in with corrections.
If you take a step back and resist the urge to correct people, can you understand how "Currying is a subset of partial application" is true?
It isn't true and i can understand why someone would make that statement. Currying and partial application both come from a functional mindset that treats functions as data, and like data also functions can be transformed.
Currying and partial application both satisfy a transformation depending on a desired context:
- Currying "widens" a function "up" (as in you don't need to know all arguments beforehand in the same context anymore)
- Partial application "narrows" a function "down" (as in arguments are contained within the context of the partially applied function)
> If you take a step back and resist the urge to correct people...
Please keep it on topic.
It is true, and you are smart enough to understand it if you stop assuming you're the only one who understands the topic. I'm specifically sticking with the wording "Currying is a subset of partial application" to make the point that you can understand what someone is trying to say even if they don't say it exactly the way you would like them to say it.
> - Currying "widens" a function "up" (as in you don't need to know all arguments beforehand in the same context anymore) > - Partial application "narrows" a function "down" (as in arguments are contained within the context of the partially applied function)
So you're saying that I'm "widening" the function "up" when I do:
increment = add 1
invert = div 1
increment = (\x -> add 1 x)
halve = (\x -> div x 2)
When I curry `add` above, isn't the argument 1 contained within the context of the partially applied function?
When I partially apply `div` above, don't I no longer have to know all the arguments (i.e. I no longer need to know the denominator 2)?
It sure seems like this up/down wide/narrow wording you're fixated on isn't a particularly better descriptions of what's going on with currying and partial application.
It mean, maybe it's just my font, but the partial applications are a bit wider on my screen. ;P
> "Currying is a subset of partial application" is true in the same sense as if "subtraction is a subset of addition". Sure, you can subtract negative values to have addition and add negative values to have subtraction, but that can't be your point, is it?
I'm not sure I understand that analogy to say it's my point.
Are you saying you would behave condescendingly toward someone who said "subtraction is a subset of addition" too?
> Please keep it on topic.
The topic skybrian started was derailed when you decided to "correct" him because you didn't make any effort to understand what he was trying to say. Your behavior is the topic now because your behavior became a problem.
This is an add function with two arguments:
add :: (Int, Int) -> Int
add (x, y) = x + y
-- addCurr :: Int -> Int -> Int
addCurr = curry add
-- increment :: Int -> Int
increment = addCurr 1
You didn't curry it, you partially applied it. This was possible, because your function add was already curried.
My mistake there doesn't negate my larger point, but I've gotta go touch grass.
Okay, writing this in Python because a) it's been a while since I wrote Haskell, b) it will let other readers read the code more easily, and c) Python clearly denotes what a partial is by having a `partial` function:
from inspect import signature
from functools import partial
def curry(f, parameters=None):
if parameters is None:
parameters = list(signature(f).parameters.keys())
if len(parameters) == 0:
return f
head = parameters[0]
tail = parameters[1:]
# I draw your attention to this line
return lambda p: curry(partial(f, **{head: p}), tail)
def divide(a, b, c):
return a / b / c
curried_divide = curry(divide)
# prints "3"
print(curried_divide(30)(5)(2)())
Do you think that makes your statement "Currying is a subset of partial application" (and doubling down on that) any more true?
After all, you can implement subtraction with just the help of addition and multiplication:
add :: Int -> Int -> Int
add a b = a + b
mult :: Int -> Int -> Int
mult a b = a * b
sub :: Int -> Int -> Int
sub a b = add a (mult (-1) b)
My critique of your original post is that you're treating English like it's a computer language where words mean very specific things. But the reality is that English is a cobbled-together bunch of words with imprecise meanings that arise from common usage. Let me reiterate: usage determines meaning, not the other way around.
You're approaching this conversation with your own preconceived notions about what the words mean and trying to force your preconceived notions onto everyone else instead of trying to understand what the other person means. It's a rude way to treat people trying to communicate with you.
I mean, it's clear that you understand the idea because you're coming up with examples that show that you understand it. Communication was successful. There's no problem with the communication. The problem is that you decided, after communication was successful, to force your preferred usage of the words on other people.
This is an extremely common interpersonal mistake that technical people make because unlike English, computer languages have very specific, objective meanings. But expecting that same objective specificity from humans speaking English isn't realistic, kind, or polite. It's one of the main reasons technical people are widely perceived as socially inept. Behaving like this hurts our careers, friendships, and romantic relationships. Doing this on HN is just a minor annoyance to everyone else, but if you do this in your life as a whole, the person you're harming most is yourself, because you're making it a pain in the ass to communicate with you.
I'm asking you to be a better reader and listener.
And look, maybe you can get skybrian or me to change the way we communicate to suit your preferences, but why? Nothing is gained. And if you spend your life trying to force people to communicate a certain way instead of trying to understand people, it's just going to be an endless war, where the only meaningful result you'll achieve is that it's harder for people to communicate with you. Is that what you want for yourself?
If you'd approached this from the perspective of "hey I think people would understand you better if you said it this other way", that would be fine. I think it's great to improve communication, and it's both up to speaker/writer and listener/reader to meet in the middle: both sides of this interaction can improve. But that's a pretty big difference between coming at someone like "you're wrong".
...because I think you'd write mathematical history if you can prove it?
> You're approaching this conversation with your own preconceived notions about what the words mean...
Peak meta, yes!
> ...to force your preferred usage of the words on other people.
Listen, currying is a defined term[0], as is partial application[1]. Those are primarily mathematic definitions, and your choice of words "...is a subset of..." is also stemming from a rather mathematical terminology if you'd ask me. Therefor its interpretation will primarily be itching logical intelligence.
Currying can be implemented by making use of a partial application, and partial application can be implemented by making use of currying a function. Neither one is a subset of the other and both are higher-order functions.
It was your choice of words with which you formed your statements, and no, I'm not going to discuss visual, linguistic, interpersonal, intrapersonal or naturalistic understandings with you on Hacker News about your intentions, I'm truly sorry. Your point "about the concept of currying" doesn't exist (yet AFAIK), feel free to imagine whatever higher concept you desire.
Even the confusion between currying and partial application is well known[2][3] and also documented on Wikipedia - you put in a prime example out of the confusion, thank you. You still double down on false statements, fine, use your languages however you want and feel free to interpret "I think you confuse currying with partial application." as a behavioral problem. It's truly amazing.
[0]: https://en.wikipedia.org/wiki/Currying
[1]: https://en.wikipedia.org/wiki/Partial_application
No, because this is an informal conversation not a mathematical paper.
Clearly you understand what is meant if someone says that subtraction is a subset of addition. You also clearly understand they're not saying it as a statement of proof.
If you can understand someone well enough to correct their usage of words, you understand them well enough that they communicated successfully. So why create a problem?
> Listen, currying is a defined term[0], as is partial application[1]. Those are primarily mathematic definitions, and your choice of words "...is a subset of..." is also stemming from a rather mathematical terminology if you'd ask me. Therefor its interpretation will primarily be itching logical intelligence.
Yes, I'm well aware, I just don't care. People use words outside their dictionary definitions all the time and if we understand it, it doesn't matter.
Perhaps you should look up the word pedant? Dictionary authors are well aware of the pitfalls of relying on definitions as prescription rather than description.
> I'm not going to discuss visual, linguistic, interpersonal, intrapersonal or naturalistic understandings with you on Hacker News about your intentions,
Well, that's your prerogative, but I'll note that you haven't said anything interesting about currying because you keep assuming your audience knows less than they do. Learning to listen at an adult level would help you to have more interesting technical discussions, too.
I can't agree here either... I know it from my own experience when i first learned about currying and partial application.
Your play at humility that you didn't understand currying and partial application in the past kinda falls flat if you then go on to less-humbly assume that everyone else in the conversation is stuck where you once were.
I understood it instead to be generalizing to a related concept, and inferred no condescension, FWIW.
So could you elaborate to me where the distinction lies here and why is there a need to "simulate" things?
function c(f, v) { ... f(v) ... }
function f2(a, b) { ... }
c(f2, "value") => b will be undefined.
c(f2, [1, 2]) => a will be set to [1, 2].
function wrapf2(b) { return f2("fixed a", b) }
function c(f, v) { ... f(...v) ... }
function c(f, v) { ... f.apply(null, v) ... }
c(f, [1])
c(f, [1, 2])
c(f, 1) // fails
In assembly, different parameters are in fully separate registers or stack entries. Interestingly, you could imagine representing tuples as C structs (that can have only one member) and always pass structs, and passing a one-member struct will actually have the exact same effect as passing a value of a primitive type.
However, I agree with the wording of the original comment: when you _pass_ some arguments to a constructor and then to a method, this is (at least conceptually) partial application.
Could you say more? I'm not sure I understand what you're saying here.
When a function needs a lot of parameters to do a calculation, these parameters can be arbitrarily grouped into records and supplied in any order. Languages have convenient syntaxes for certain ways of grouping parameters together.
For example, a closure creates a group of parameters in the form of a function.
No, it isn't; it's a different operation.
Currying refers to building (effectively) functions of multiple arguments out of only one argument functions (such as in a language that has only those).
A curried function is not understood to have been applied, partially or otherwise; none of its arguments have been bound to values, thereby reducing its arity.
Partial application is an operation that requires one or more arguments. Currying does not require arguments; rather, the result of currying requires arguments (all of them).
There is a sort of partial application (effectively) going on when the curried function is applied to the arguments, which has to be done one argument at a time through the chain. At each step, one more argument is bound, and fewer remain.
What currying in Haskell and any other ML does, is the following as Javascript. Let's say we have a function with four parameters `func(a, b, c, d) {return a + b + c + d;}`, then the curried version is the following:
func = (a) => {
return (b) => {
return (c) => {
return (d) => a + b + c + d;
}
}
}Instead of assuming you know better and jumping in with a correction, could you reread that post and assume that the person knows what they're talking about but isn't communicating exactly the way you would have communicated it? I.e., read with the intent of understanding intent, rather than read with the intent of correcting?
My answers are almost always less intented for the person who's post I'm responding to, but more for a general audience. As others have already posted the part about "currying isn't partial application", and I mainly wanted to add a (hopefully) understanable example.
And I would say that taking the OP's post as if he doesn't exactly know, what currying means in comparison to partia application _is_ the more favourable interpretation of their post.
Same. I don't expect you're going to admit your mistake, but I'm pointing it out because the general audience is the sort of audience who is prone to this mistake (which I only know because I myself have been corrected for making this mistake).
> As others have already posted the part about "currying isn't partial application", and I mainly wanted to add a (hopefully) understanable example.
And in doing so, you're making the same mistake as those other posters, by assuming skybrian doesn't know what currying and partial application are. You're not doing your audience any favors by painting skybrian's post as if he said something wrong.
> And I would say that taking the OP's post as if he doesn't exactly know, what currying means in comparison to partia application _is_ the more favourable interpretation of their post.
How so?
It is easy to guess that the original comment meant that a manual re-write of a function:
foo(a,b) {...}
class Foo {
Foo(a) {...}
operator()(b) {...}
}
// curried foo:
foo(a)(b)
// class-curried foo:
Foo(a)(b)
Congratulations.
Your example is currying in a manual fashion, so two questions remain for me:
1. How would you tell the compiler to do it for you, as a function transformation?
2. How would you curry a function with 3+ arguments?
#include <iostream>
#include <functional>
template <typename Ret, typename First, typename ...Rest>
class Curry {
std::function<Ret(First, Rest...)> fn;
public:
Curry(std::function<Ret(First, Rest...)> fn): fn(fn) {};
Curry<Ret, Rest...> operator()(First arg) {
return Curry<Ret, Rest...>{[this, arg](Rest... args) {
return this->fn(arg, args...);
}};
}
};
template <typename Ret, typename Arg>
class Curry<Ret, Arg> {
std::function<Ret(Arg)> fn;
public:
Curry(std::function<Ret(Arg)> fn): fn(fn) {};
Ret operator()(Arg arg) {
return this->fn(arg);
}
};
int uncurried(int a, int b, int c) {
return a + 2*b + 3*c;
}
int main() {
auto curried = Curry<int, int, int, int>{uncurried};
std::cout << curried(1)(2)(3) << std::endl;
}Though if enough people share the confusion, I guess it becomes an alternative definition. Language evolves.
Also, in any case, a constructed object is nothing like a partially applied function, so the parallel drawn is not useful. It seems entirely reasonable in this case to assume that the poster does not have sufficient experience or knowledge.
A method is a function with convenient syntax. Some of its arguments come from the “this” parameter. If the object is immutable and the method has no side-effects, it’s a pure function.
Converting a function to an immutable class with a method is a mechanical refactoring that I sometimes do, when the class has an intuitive name. The code does the same thing.
I have to concur with grandparent and also with user https://news.ycombinator.com/user?id=whilenot-dev in a sibling subthread.
E.g. if we have (lambda (x y z) (+ x y z)) converted into the curried form (lambda (x) (lambda (y) (lambda (z) (+ x y z)))), then while we do not yet have partial application, we can then partially apply just by passing arguments.
That is to say, we are partially applying in the abstract sense; if we pretend we still have a (lambda (x y z) ...) in our abstract semantics, then when we pass a value for x to the curried function, we then have effectively partially applied this abstract function, resulting in something that needs just the (y z) arguments now.
Languages that support implicit partial application erase the difference between f x y and (f x) y. That is to say, the programmer doesn't have to know whether f x y is a call two a function f with two arguments, or whether there is a partial application (f x) which binds the x argument, followed by an application of that resulting function to argument y.
Now if the language substrate is based on one-argument functions, under the hood, so that all functions with two or more arguments are implicitly transformed into one argument functions by currying, then partial application is "free", so to speak. The syntax may let you write f x y to call a function of two arguments, but the implementation is actually doing (f x) y.
Thus currying can support partial application in a similar way to how transformation of a program to CPS (continuation passing style) supports continuations. Partial application is "free" in a curried program similarly to how continuations are "free" in a CPSed program. Under CPS, you already have the return continuation as a hidden argument, so call/cc does nothing more than reveal what is hidden. Under currying, you already have a lambda that takes just one argument, and gives you a lambda that takes the next one.
Are you being serious? The fact that closures and objects are dual is a frequently made observation. It’s not something the poster invented and it’s not (usually) controversial.
In addition to that, I don't always find the constructor/method approach more readable. It _can_ be readable, if you design your API with care; however, it is common to group related data into records in the FP world as well, which mimicks OOP constructors, in a sense.
If currying isn’t built-in, you can emulate it. In TypeScript you need to do it explicitly, which means anticipating that it will be used, and whenever I try that, I later decide that it’s needlessly obscure and rewrite the code some other way.
Even with built-in currying, you still need to anticipate usage by changing the order of the parameters, based on which ones you expect the callers to have first. It’s less general than writing an inline function with exactly the parameters you need. TypeScript has nice syntax for defining tiny, one-off functions and I think that’s better than having currying.
One side-effect of having currying in a language is that it discourages naming things, and I think that’s often bad for readability. A chain of method calls gives you a lot of names to look up and a place to put documentation.
It makes the code way less readable:
* more difficult to distinguish arguments and return values (there's a reason most languages have distinct syntax for them)
* it encourages you to put your arguments in an order that might not be the most logical
And on top of that it only works for the last argument(s).
Feels like a lot of disadvantages to allow an overly clever trick that you can do in other languages much more readable using lambda functions. And those work for any arguments, not just the last one(s).
or (where available) sections
It's a shame the only language that did partial application well is, weirdly, Python.
I guess you were talking about `functools.partial`, which is basically the same as currying and also only works on the last arguments. It's better to use lambda functions.
Also Python is far from the only language to have a function like that, e.g. see C++'s `std::bind` which nobody* uses since lambdas were supported.
*standard HN disclaimer
I was talking about `functools.partial` yes, but it can work on any arguments in order, using keyword arguments.
e.g.
def copy(source, dest):
.....
copy_to_temp = partial(copy, dest="/tmp/")
copy_from_temp = partial(copy, source="/tmp/")how is `add a b c = a + b + c` being curried an issue to you?
After like ten or fifteen hours of trying to understand what currying is, I still have no idea, and frankly don't care. If I see it in a codebase it'd just be a big red flag to avoid that job altogether.
Software is in good hands.
When you're writing Haskell, you should write idiomatic Haskell. Currying is part of that. It's a trivial concept and we use it liberally at work. If you're writing JavaScript though, I think it's a different story. I don't think JavaScript lends itself to FP in the way that Haskell or Elm does, and trying to make it do that only makes a project harder to work on.
The entire codebase was like that. It stood out to me as the work of someone who was very smart but worked alone and never had to work with a team, and never considered what someone trying to retrace his mental process would have to go through. He left zero documentation or comments, built the whole thing in a rush, sold it to another company, and we were the ones hired later to clean up his mess.
Some of it was very good. He was really good at efficiently encoding low level network traffic over packet encodings he invented or heavily modified. Seemed like he would've been a brilliant signals engineer or cryptologist. But having to work with his ordinary business logic code was pretty nightmarish, if interesting from a reverse engineering and psychology point of view.
It's just not how I would ever want to write code meant for mere mortals. But then again, he's a multi millionaire now and I'm a rando nobody living paycheck to paycheck, so I'm in no place to judge lol.
If he had not made such a big mess, you might not be getting this paycheck to clean it up. I think they call this “creating scope for other people” at big companies, real staff engineer stuff. =)
Maybe you could recall which learning materials you used?
Example
add 1 2 // add is curried, you can use it like this, the "normal" way, returns 3
p = add 1 // since add is curried I can also provide just the first argument
p 2 // and then apply the last argument to the intermediate results, returns 3
In Haskell curried form is the default and the syntax and semantics really suits it. In JS non-curried is the default and it just looks odd, and you need libraries to support it. That library you mentioned doesn't look nice to use.
https://wiki.haskell.org/Pointfree
There is a sliding scale and even at the Haskellers have a limit of how much point-free they can take.
In JavaScript use of the style is problematic in another way: unlike Haskell in JS the length of the argument list is variable, which means that if someone adds another argument to either the caller or callee it can break the code in subtle and unexpected ways.
For this reason it’s good practice to always wrap functions being passed as arguments to another function in a lambda expression.
i.e instead of writing: g(f), you should usually write: g(x => f(x)) unless you have good reason to believe that g(f) is safe. This makes it difficult to use point-free style at all in JS.
For example arr.map(f) is generally unsafe in JS because if `f` adds an extra default argument of type number then your code will break and even TypeScript won’t let you know.
Things like currying are fun but like anything that encourages gratuitously deep call trees, they wreck your locality of reference (as a developer) and force you to 'decompile' the code in your head in order to understand it. I'm sure that a top level developer would be able to write curried JS in such a way that it was clear and readable to another top level developer, but that's not the point. The code's not for you, it's for newbie who gets stuck with it when you move on.
What if you forget, not in quotes, to give the second argument? Why on earth would you want to get a type error in a completely different part of the code because you got a function instead of an integer? Wouldn't it be desirable to have the compiler just tell you that you forgot the second argument where you forgot the second argument?
Is it really valuable to be able to do:
p = add 1
inc = (\x -> add 1 x)
inc x = add 1 x
I mean, I get the idea, they're following the lambda calculus, but this is one of the things that should have been dropped when they started to expand the lambda calculus to a general purpose programming language.
I will get a type error and it will take me 2-3 seconds to figure out what it is about.
> Why on earth would you want to get a type error in a completely different part of the code because you got a function instead of an integer?
Why would it be in a completely different part of the code? At most it would be 2 lines away, but usually on the same line.
You should really screen capture yourself coding sometime. On a large codebase you're lucky if the compiler even runs in 10 seconds.
> Why would it be in a completely different part of the code? At most it would be 2 lines away, but usually on the same line.
Because possibly you return the partial assuming it's a number, and try to use it somewhere else, possibly even in another file.
Sorry, I must've been more explicit instead of implying certain usage patterns. What I meant here is that I have a hard time imagining this happening because I would start working on a function by writing its type signature. Unless my types check out, I won't be able to mark this function as "done" and jump to another part of code. So the situation "you return the partial assuming it's a number" simply can not happen, that's exactly what type checking is for. By the time I use it in another place, it has to already have been type checked.
I think writing out type signatures is The Right Way, but it does take time, and The Right Way doesn't always happen on complicated projects with close deadlines.
But I don't think this is a problem in practice for whatever reason. Haskell does have a lot of "big scary type error, wtf" type problems, but not from currying. Or at least it did have when I last used it 5 years ago, it may have improved in the compiler error message front.
Also it is better than JS anyway (low bar):
> function add(a,b) {return a + b}; add(1);
<- NaN f a b = g(a,b) = f' b a
(x^2)^3 = x^(2*3) = (x^3)^2"Whoever has the gold makes the rules"
(*maybe the ones who spent their summers at Artek were learning "whoever makes the rules has the gold"?)
Dynamically typed functional retrofit on with no type checking though? Hell no, that's a write-once read-never mess of unmaintainable shite.
(I also have been on a team with The Guy Who Wanted To Ramda, and I'm someone who writes build scripts in ocaml)
Inheriting that codebase felt like watching one of those serial killer dramas... obviously a really smart guy, but with a psychology unlike most people I've ever met, and really hard to follow as a normal person. I still see him with a mixture of respect, awe, curiosity, and wonder.
The thing is, none of the stuff he gave is was actually complicated. It's just a basic business dashboard. But he reinvented almost every single part of it in totally nonstandard ways that the whole project was less about coding and more about anthropology and forensic psychology.
I have doubts on whether this is a sincere attempt at understanding the concept. The linked wiki page is like a five minute read and that's enough to understand the concept at a user's level.
What I suspect is that something else is tripping you up and causing code readability issues; but since you didn't know what currying is you incorrectly ascribed currying as the problem.
Uncurried:
((x, y) => x * y)(3, 5) === 15
Curried:
(x => y => x * y)(3)(5) === 15
If you don't understand that, your problem is that you don't understand anonymous functions (lambdas), not that you don't understand currying.
just my 2 ct
https://en.wikipedia.org/wiki/Tacit_programming
https://medium.com/@jesterxl/real-world-uses-of-tacit-progra...
when you use tacit programming and currying together you can write code in a "bash-like" pipe style which not only makes the program more readable but also is less error prone.
high level abstraction can make you very productive, but it can also be rather unreadable. e.g. two code snippets in python (yes this is valid python code with some operator overloading):
# compute pi by drawing random numbers in a circle
1000000 >> ψ( ψ(χ>>op("(x**2+y**2)**0.5<1")@rlµ<<χ)>>Σ*4>> _/_)
# 10 fibonacci numbers
[x:=[1,1]] + [x := [x[1], sum(x)] for i in range(10)]
just my 2 ct
x = y 3
vs
x = partial y 3
I would vastly prefer the latter. And if you do it a lot you could have a symbol for it in your language.
Your examples are unrelated to currying though...
You can make code much shorter by removing all the application-specific names and only using very abstract, domain-independent names or symbols. The result can be seen in complicated regular expressions, array languages, bash scripts, and so on. In the wrong hands, these are all notoriously unreadable.
But you can also go to the other extreme and give every little thing a very long name, and that’s less readable in its own way. Bob Nystrom wrote a nice article about how to combat that tendency. [1]
Naming things is an art. In functional languages, let expressions are convenient and useful. When you feel like you don’t want to define another function, sometimes it’s better to resist that tendency and think about a better name.
[1] https://journal.stuffwithstuff.com/2016/06/16/long-names-are...
When it comes to names, the binding and lexical scope and position in the AST helps me read the code more than the English pronunciation.
Tbh if I have a stream of English words in my head reading Haskell, it's probably already meh code at best :S
I'd say I see more Haskell code made unreadable due to over-naming than under-naming in the wild (i.e. industry)
Reading through these comments, it's clear that currying isn't clearly understood, which makes me doubt it's worth the cognitive load to use in a codebase.
In my limited Haskell experience, you can mostly ignore that functions are curried, but every once in a while, someone uses it, and it has never, in my experience, made the code easier to understand, because the currying happens implicitly.
The more general case of currying is partial application, where instead of a function taking only its first argument and returning a function that takes its next argument, you can apply a function any of it's arguments and return a function that takes the remaining arguments. So if you have:
div x y = x / y
invert = (\x -> div 1 x)
-- invert is a partial application of div to the 1 as first argument
halve = (\x -> div x 2)
-- halve is a partial application of div to 2 as the second argument
Which is because lambda calculus does not have functions with more than one parameter, I guess.
And in the lambda calculus, it makes a ton of sense, because it allows you to break proofs into smaller chunks more easily.
But in a general-purpose programming language where the proofs are automated, I think this just makes the code less communicative of programmer intent.
gears = filter ((==2) . length)
. map (neighbouringNumbers numbers)
$ filter ((=='*') . fst) symbols
gears = (\xs -> filter ((\x -> x == 2) . length) xs)
. (\xs -> map (\x -> neighbouringNumbers numbers x) xs)
$ filter (\(c,_) -> c == '*') symbols
Eh, but that's my point: I want less cognitive load. Currying is another thing that I have to keep in the back of my mind, and Haskell already has way too many of those, and it's not a particularly useful thing. I've got limited space in the back of my mind for things and if I'm going to keep things in the back of my mind I want them to be useful. I mean, if your argument in favor of currying is that it saved you a few keystrokes in that example, color me unimpressed.
Maybe I'm just too stupid to understand easily, but the "simple" example you're giving is taking me a while to understand. If a junior dev on my team submitted that in a PR I'd send it back asking them to break it up into a few smaller named functions and probably not use a partial application at all. Something like "I know it's fun to be clever but let's make this easier for the next person who has to figure out what it does".
I guess what I'm saying is that for that example it seems like you're going for tersity rather than clarity for future readers of the code. If you were going for clarity you probably wouldn't write it either of the ways you've given.
And in big projects clarity is the number 1 concern[1]. In toy examples like this I can slog through and figure something like this out, but when it's 30 functions written like this, all calling each other in the most clever ways possible, nobody can figure it out.
[1] EDIT: Okay #2 after correctness perhaps. But it becomes hard to achieve correctness without clarity as a project grows.
gears = filter ((==2) . length)
. map (neighbouringNumbers numbers)
$ filter ((=='*') . fst) symbols
The given Haskell code reads naturally to me now. (I'm only a little uncertain because I can't write Haskell.) It would have been line noise to me before before point-free style clicked.
I tend to read Haskell code in articles from right to left, and it reads: "Choose the symbols whose first letter is '*', get their respective (neighboringNumbers numbers), and choose the results whose length is 2". I read (neighboringNumbers numbers) as if it were a noun.
I don't know how this clicked, but I'm pretty sure it has nothing to do with stupidity. Perhaps it was by chance, or perhaps it was by banging my head against the wall enough times.
Would I introduce point-free style in a JS codebase? Probably not. People are unfamiliar with this kind of style. Would I introduce this style in a Haskell codebase? Almost certainly, because it's clear and I think it reflects how Haskell programmers think.
Expert jargon can sometimes be useful, but it often obscures things that would be pretty simple if written some other way.
With Haskell there’s a tension between saying “I only care about writing for other expert programmers” and “more people should learn Haskell.” The idioms are part of the turnoff.
However as I mentioned, since it is not true that most people can read FP code, I mostly avoid using it. The example comes from my solution to AoC2023's Day 3, "Gear Ratios", which is just about the only thing I use Haskell for.
That doesn't mean that using it doesn't have practical applications, since being used to multiple paradigms opens you up to unconventional solutions. I've recently sped up a MATLAB function ~100x through using a more functional style to manipulate memory more efficiently. Async/await, certain styles of modern iterator manipulation and generators escaped F#, CLU and others into C# and from there into the world at large specifically because Microsoft programmers saw a problem they had had a solution for in previous functional projects. So it's not all useless.
For the record, a more imperative version could be written as
symbols = [ imagine there's stuff here ]
gears = []
for (symbol, coord) in symbols:
if symbol == '*':
ns = neighbouringNumbers(coord)
if len(ns) == 2:
gears.append(ns)
gears = [ neighbouringNumbers(coord)
for symbol,coord in symbols
if symbol == '*' and len(neighbouringNumbers(coord)) == 2 ]
Personally I just find nowadays that having to comprehend "it collects neighbour-pairs from '*' symbols" from the imperative code harder than having that be the thing that is actually written down.
For example, if you’re looking at Lisp code and you don’t know whether an outer term is a function, macro, or special form, you really don’t understand anything inside it except at the most superficial level. It might as well be JSON. Macros aren’t marked, so any unknown term might be a macro. (Knowing the surface syntax is still helpful, though. Well-known syntaxes for data are useful.)
With Forth it’s pretty bad, too. Not knowing what a single word does means that you don’t know what’s on the stack afterwards.
A Unix pipeline is a bit more orderly since you know that there are streams of bytes. You know the command names and the arguments to each command. But if you don’t know what a command does, you don’t know much at all about what the data looks like after that point.
I find currying and point-free programming to be pretty opaque because I can’t tell where the function calls are or how many arguments each function takes from usage. I don’t know what the dataflow looks like. It seems like you need to know some precedence rules too?
Languages with conventional function call syntax, augmented with named parameters, seem better. I can tell where the function calls are and where the inline functions are. Augmented with reasonable names for temporaries, I can make reasonable guesses about what the code does.
These syntax concerns seem independent of whether it’s a functional or imperative language? Making reasonable guesses is what we do when we read pseudocode. Maybe what I’m saying is that some syntaxes seem better for pseudocode than others, and I like languages that look like pseudocode better.
I suspect that these syntax differences also have an effect on how good the error messages are when you screw up.
This is true, but:
- the name of the operator is typically a word that you can easily search for in the documentation or on the web, or with "jump to definition" in your editor, if it's something locally defined in the source tree.
- you usually understand the shape of what is inside it. You know what parts of the program you are looking at are arguments to that mysterious operator and which are not. If asked which expression is the third argument of that operator, you can easily find it and know where it begins and ends.
Yes, that's a problem.
There are two clues:
* Macros typically have naming conventions. For example anything beginning with DEF should be a defining macro, not a function. Anything with DO- will be a control structure. Anything with WITH- will be a scoping macro. And so on. Avoid active names like CREATE- and use DEFINE- instead. CREATE-CLASS would be a function, DEFINE-CLASS would be a macro.
* In source code the enclosed code typically has syntax and special indentation, when used with macros. Functions have certain uniform indentation rules.
(create-class 'container-ship
:superclasses '(ship)
:slots '((max-number-of-containers :type integer))
:documentation "our new container-ship class")
The macro looks different. The first important things like name and superclasses are on the first line. The other parts of the class specification follow and are indented by two characters.
(define-class container-ship (ship)
((max-number-of-containers :type integer))
(:documentation "our new container-ship class"))
I write Python a great deal for a living these days and the Python code isn't much clearer to me. In both the Python and Haskell examples I can tell what it's doing (except the opaque neighbouringNumbers)--I just can't tell why it's doing it.
This had to be said! Sure you can make the argument that this improves your productivity as a coder, or makes the code more concise, but to someone coming along cold and trying to pick apart your code to fix something it's going to be a nightmare.
Having gone through it, I highly recommend the book; especially to anyone knowledgeable about any 2 and interested in the third.
I love Haskell. I love writing it, and reading it. Haskell is a beautiful programming language. One where I felt immediately at home in and comforted by.
Currying is one of the foundational concepts of the language, but I do think it is one aspect of the language the community treats excessively sacredly.
In Haskell, function composition has right associativity. What this means, in the event of a function that takes in 3 Integers as arguments and returns a Double would have a type definition of:
FN_NAME :: Int -> Int -> Int -> Double
fn0 :: Int -> Int -> Int -> Double
fn0 x y z = (fromIntegral (x + y)) / (fromIntegral z)
fn1 :: Int -> (Int -> Int -> Double)
fn1 x y z = (fromIntegral (x + y)) / (fromIntegral z)
fn2 :: Int -> (Int -> (Int -> Double))
fn2 x y z = (fromIntegral (x + y)) / (fromIntegral z)
ghci> fn0 1 2 3 -- 1.0
ghci> fn1 1 2 3 -- 1.0
ghci> fn2 1 2 3 --1.0
As I understand it, the compiler sees ALL functions as a composition of functions of one input.
This is pretty cool, and a powerful foundation to build on. Where I take a bit of issue is when the Haskell community allows the rigor of the type definition to carry some of the weight of the expressiveness of the function definition.
Each function definition ('=') pairs with a type definition ('::'), as the ones above, ie. an example from the promoted book:
type R = Double
type VecDerivative = (R -> Vec) -> R -> Vec
vecDerivative :: R -> VecDerivative
vecDerivative dt v t = (((v (t + dt/2)) ^-^ (v (t - dt/2))) ^/ dt)
velFromPos :: R -- dt
-> (R -> Vec) -- position function
-> (R -> Vec) -- velocity function
velFromPos = vecDerivative
-- random example of 'vector-valued function'
v1 :: R -> Vec
v1 t = ((2 *^ (t**2 *^ iHat)) ^+^ (3 *^ (t**3 *^ jHat)) ^+^ (t**4 *^ kHat))
ghci> vecDerivative 0.01 v1 1 -- vec 3.999999999999937 9.000074999999885 4.000099999999962
ghci> velFromPos 0.01 v1 1 -- vec 3.999999999999937 9.000074999999885 4.000099999999962
But I always felt this ~implicit syntax is needlessly aggressive to newcomers.
I also pathologically write my Haskell code like a Lisp because the Haskell community's celebration of the complex precedence structure of its order of operations causes practitioners to appear, to my eyes, over confident in their ability to sight read their own work's order of operations. ;P
ghci> sqrt 2 + 1 * 3 + 3 * 2 + 1 / 7 -- 10.557070705230238
ghci> ((sqrt 2) + ((1 * 3) + ((3*2) + (1 / 7)))) -- 10.557070705230238
In the face of the ability to write the functions explicitly and with expressive parentheses, it seems the answer is "because you can".
>>> math.sqrt(2) + 1 * 3 + 3 * 2 + 1 / 7
10.557070705230238
Due to Haskell's rigor in regard negative numbers:
ghci> -1 + 2
1
ghci> 2 + -1
<interactive>:12:1: error:
Precedence parsing error
cannot mix ‘+’ [infixl 6] and prefix `-' [infixl 6] in the same infix expression
ghci> 2 + (-1)
1
ghci> -1 * 3
-3
ghci> 3^-1
<interactive>:3:2: error:
• Variable not in scope: (^-) :: t0 -> t1 -> t
• Perhaps you meant one of these:
‘^’ (imported from Prelude), ‘-’ (imported from Prelude),
‘^^’ (imported from Prelude)
ghci> 3^^-1
<interactive>:4:2: error:
• Variable not in scope: (^^-) :: t0 -> t1 -> t
• Perhaps you meant ‘^^’ (imported from Prelude)
ghci> 3**-1
<interactive>:5:2: error:
• Variable not in scope: (**-) :: t0 -> t1 -> t
• Perhaps you meant ‘**’ (imported from Prelude)
ghci> 3**(-1)
0.3333333333333333
ghci> sqrt 2 + 1 * 3 + 3 * 2 + 1 / 7
10.557070705230238
ghci> sqrt $ 2 + 1 * 3 + 3 * 2 + 1 / 7
3.3380918415851206
ghci> -sqrt 2 + 1 * 3 + 3 * 2 + 1 / 7
7.728643580484048
ghci> -sqrt $ 2 + 1 * 3 + 3 * 2 + 1 / 7
<interactive>:25:1: error:
• Non type-variable argument in the constraint: Num (a -> a)
(Use FlexibleContexts to permit this)
• When checking the inferred type
it :: forall {a}. (Floating a, Num (a -> a)) => a
ghci> sin -1
<interactive>:7:1: error:
• Non type-variable argument in the constraint: Num (a -> a)
(Use FlexibleContexts to permit this)
• When checking the inferred type
it :: forall {a}. (Floating a, Num (a -> a)) => a -> a
ghci> (sin -1)
<interactive>:10:1: error:
• Non type-variable argument in the constraint: Num (a -> a)
(Use FlexibleContexts to permit this)
• When checking the inferred type
it :: forall {a}. (Floating a, Num (a -> a)) => a -> a
ghci> sin (-1) -- -0.8414709848078965
ghci> (sin (-1)) -- -0.8414709848078965