A case against currying
emi-h.com
A case against currying
1–10 of 135 posts
Re: A case against currying
#2What benefit does drawing a distinction between parameter list and single-parameter tuple style bring?
I'm failing to see how they're not isomorphic.
Re: A case against currying
#3Currying was recently removed from Coalton: https://coalton-lang.github.io/20260312-coalton0p2/#fixed-ar...
Re: A case against currying
#4What benefit does drawing a distinction between parameter list and single-parameter tuple style bring? I'm failing to see how they're not isomorphic.
The tuple style can't be curried (in Haskell).
Re: A case against currying
#5What benefit does drawing a distinction between parameter list and single-parameter tuple style bring? I'm failing to see how they're not isomorphic.
The tuple style can't be curried (in Haskell).
That's not what I'm talking about.
The article draws a three way distinction between curried style (à la Haskell), tuples and parameter list.
I'm talking about the distinction it claims exists between the latter two.
Re: A case against currying
#6I'm biased here since the easy currying is by far my favourite feature in Haskell (it always bothers me that I have to explicitly create a lamba in Lisps) but the arguments in the article don't convince me, what with the synctactic overhead for the "tuple style".
Re: A case against currying
#7What benefit does drawing a distinction between parameter list and single-parameter tuple style bring? I'm failing to see how they're not isomorphic.
That's a fair point, they are all isomorphic.
The distinction is mostly semantic so you could say they are the same. But I thought it makes sense to emphasize that the former is a feature of function types, and the latter is still technically single-parameter.
I suppose one real difference is that you cannot feed a tuple into a parameter list function. Like:
fn do_something(name: &str, age: u32) { ... }
let person = ("Alice", 40);
do_something(person); // doesn't compile
Re: A case against currying
#8What benefit does drawing a distinction between parameter list and single-parameter tuple style bring? I'm failing to see how they're not isomorphic.
They are isomorphic in the strong sense that their logical interpretations are identical. Applying Curry-Howard, a function type is an implication, so a curried function with type A -> B -> C is equivalent to an implication that says "If A, then if B, then C." Likewise, a tuple is a conjunction, so a non-curried function with type (A, B) -> C is equivalent to the logic statement (A /\ B) -> C, i.e., "If A and B then C." Both logical statements are equivalent, i.e., have the same truth tables.
However, as the article outlines, there are differences (both positive and negative) to using functions with these types. Curried functions allow for partial application, leading to elegant definitions, e.g., in Haskell, we can define a function that sums over lists as sum = foldl (+) 0 where we leave out foldl's final list argument, giving us a function expecting a list that performs the behavior we expect. However, this style of programming can lead to weird games and unweildy code because of the positional nature of curried functions, e.g., having to use function combinators such as Haskell's flip function (with type (A -> B -> C) -> B -> A -> C) to juggle arguments you do not want to fill to the end of the parameter list.
Re: A case against currying
#9I'd got a step further and say that in business software, named parameters are preferable for all but the smallest functions.
Using curried OR tuple arg lists requires remembering the name of an argument by its position. This saves room on the screen but is mental overhead.
The fact is that arguments do always have names anyway and you always have to know what they are.
Re: A case against currying
#10What benefit does drawing a distinction between parameter list and single-parameter tuple style bring? I'm failing to see how they're not isomorphic.
Probably just that having parameter-lists as a specific special feature makes them distinct from tuple types. So you may end up with packing/unpacking features to convert between them, and a function being generic over its number of parameters is distinct from it being generic over its input types. On the other hand you can more easily do stuff like named args or default values.