Timeline for A language based on limiting amount of arguments passed to functions
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 23, 2016 at 2:14 | comment | added | Ian | You were correcting the answerer. The answerer has the mechanism correct. You have the "spirit" of the mechanism but not the mechanism itself correct. In contexts like these the distinction matters. | |
| Jun 23, 2016 at 2:11 | comment | added | Ryan Reich |
@Ian Okay, if that's your point then at worst I'm mostly right, and only because I didn't actually say "Haskell's currying reduces a function apparently with n arguments to a function with one argument returning another function apparently with n - 1 arguments". Syntactically, f a b c = ((f a) b) c, where the left-hand side has apparently got three arguments.
|
|
| Jun 23, 2016 at 2:02 | comment | added | Ian | Not quite: they don't take higher numbers of arguments in the first place. They just pretend. | |
| Jun 23, 2016 at 1:56 | comment | added | Ryan Reich | @Ian "in Haskell all functions take 1 argument and return either a non-function value or another function which also takes 1 argument. This is built into the associativity of ->: a->b->c is a->(b->c)." That's exactly what I said. | |
| Jun 23, 2016 at 1:17 | comment | added | Josh Grosso | I can't feel and help as though this is dodging the question/missing the point.... What if you could only curry twice in a row? | |
| Jun 23, 2016 at 0:34 | comment | added | Ian | @RyanReich You're right that you can see a "ghost" of the "number of arguments" of a Haskell function in its type signature. It's a ghost rather than a true signature because in general you have no way of knowing whether the last type variable in the signature is also a function type. At any rate, this ghost being there doesn't invalidate the fact that in Haskell all functions take 1 argument and return either a non-function value or another function which also takes 1 argument. This is built into the associativity of ->: a->b->c is a->(b->c). So you are mostly wrong here. | |
| Jun 22, 2016 at 20:00 | comment | added | Ryan Reich | Actually, Haskell's currying reduces a function with n arguments to a function with one argument returning another function with n - 1 arguments. | |
| Jun 22, 2016 at 14:44 | comment | added | Yakk |
@DocBrown With decent power and operator overloading, I can take a curry language and make it look like an uncurried language. Example: f *(call_with: a,b,c,d,e) Overload call_with : to begin a chain, , to extend the chain, and * on the LHS to invoke f by passing it each of the contents of the chain one at a time. A sufficiently weak operator overloading system just makes the syntax cumbersome, but that is the fault of the operator overloading system more than anything.
|
|
| Jun 22, 2016 at 11:05 | comment | added | Doc Brown | "has exactly zero impact" - The OP's question was if the readibilty of the code would increase or decrease, and I guess you do not claim such a design decision for a language has no impact on that, do you? | |
| Jun 22, 2016 at 10:58 | comment | added | user232573 | That is if you allow functions to be returned, of course. Even if not, all you have to do is have the next function called in the main program. I.e. you could have 1+1+1 where the first addition is a function which returns a function for additional addition, or it can simply be called twice. The latter style would be, in theory, cleaner, or am I mistaken? | |
| Jun 22, 2016 at 10:48 | history | answered | Jörg W Mittag | CC BY-SA 3.0 |