3 ms·

Am I the only one who thought about currying here? I mean, neither the ticket nor the thread mentions it. I don't think it's such an alien concept to people. T

by esjeon 4y ago

Am I the only one who thought about currying here? I mean, neither the ticket nor the thread mentions it. I don't think it's such an alien concept to people. TBH, with my full sincerity, this isn't really a way to solve the problem. Currying has been used for decades for reasons. For-loop isn't the only place where you introduce outer-scope variables into an immediate function. You can always have other variables involved, and you'll still have to be careful. Even though this change will reduce the absolute number of bugs, people will still have the same issue.

justinpombrio 4y ago
Currying is the observation that a function that takes a pair as an argument, `(a, b) -> c`, is equivalent to a function that returns a function: `a -> (b -> c)`. What's that have to do with for loops?
quietbritishjim 4y ago
Are you sure you mean currying? Currying is where you transform a function taking multiple arguments into a function that only takes one of the arguments and returns another function which takes one of the remaining arguments which (...recursively). Maybe you meant partial function application? Even that doesn't seem relevant, given that the function is actually being called immediately in the first example.
- esjeon 4y ago
  Hmm maybe it wasn't a common usage of the name. IIRC some people did call this "currying" in some imperative languages, though never did so in actual FP nor Lisp. You see, clearly this technique here doesn't really have any name. I also think "currying" and "partial application" kinda-sorta make sense. Unbound variables in a "immediate function" are merely hidden parameters of the function if analyzed semantically. The question is whether you pass them by-ref or by-value.
  - jerf 4y ago
    Yes, some people misuse the concept of currying in the wild. It really shouldn't be changed from its FP definition, because it is fundamentally different from partial application. Basically currying is only useful in Haskell. If you don't build it into your compiler as a first-class citizen you're going to be forever fighting a proliferation of closures in your generated code and then trying to optimize them back out. This is not a wise approach to language design. Partial application is the better solution in imperative languages. It is also not relevant to this discussion in the slightest, because the behavior of allocation and how those are passed into closures is independent of the question of how you spell those closures in code. You can easily build currying or some syntactic partial application into Go but leave this problem there, and you can easily fix this problem without building currying or partial application in.
    - tialaramex 4y ago
      > Basically currying is only useful in Haskell. This seems like a weird take. Currying was a completely natural thing to do in SML for example, why would it only be "useful" in Haskell ? I agree that currying isn't likely to be the solution to any problem you have in say, Rust or Java. But "only useful in Haskell" jumped out as a weird claim.
      - jerf 4y ago
        Because SML is effectively dead and the only living language where it is useful is Haskell. It is not practical to discuss programming languages if one must include every dead language, every academic language every conceived of in some paper somewhere, every language sitting as a years-dead GitHub repo, etc.

by esjeon 4y ago

justinpombrio 4y ago

Currying is the observation that a function that takes a pair as an argument, `(a, b) -> c`, is equivalent to a function that returns a function: `a -> (b -> c)`. What's that have to do with for loops?

quietbritishjim 4y ago

Are you sure you mean currying? Currying is where you transform a function taking multiple arguments into a function that only takes one of the arguments and returns another function which takes one of the remaining arguments which (...recursively). Maybe you meant partial function application? Even that doesn't seem relevant, given that the function is actually being called immediately in the first example.

esjeon 4y ago
Hmm maybe it wasn't a common usage of the name. IIRC some people did call this "currying" in some imperative languages, though never did so in actual FP nor Lisp. You see, clearly this technique here doesn't really have any name. I also think "currying" and "partial application" kinda-sorta make sense. Unbound variables in a "immediate function" are merely hidden parameters of the function if analyzed semantically. The question is whether you pass them by-ref or by-value.
- jerf 4y ago
  Yes, some people misuse the concept of currying in the wild. It really shouldn't be changed from its FP definition, because it is fundamentally different from partial application. Basically currying is only useful in Haskell. If you don't build it into your compiler as a first-class citizen you're going to be forever fighting a proliferation of closures in your generated code and then trying to optimize them back out. This is not a wise approach to language design. Partial application is the better solution in imperative languages. It is also not relevant to this discussion in the slightest, because the behavior of allocation and how those are passed into closures is independent of the question of how you spell those closures in code. You can easily build currying or some syntactic partial application into Go but leave this problem there, and you can easily fix this problem without building currying or partial application in.
  - tialaramex 4y ago
    > Basically currying is only useful in Haskell. This seems like a weird take. Currying was a completely natural thing to do in SML for example, why would it only be "useful" in Haskell ? I agree that currying isn't likely to be the solution to any problem you have in say, Rust or Java. But "only useful in Haskell" jumped out as a weird claim.
    - jerf 4y ago
      Because SML is effectively dead and the only living language where it is useful is Haskell. It is not practical to discuss programming languages if one must include every dead language, every academic language every conceived of in some paper somewhere, every language sitting as a years-dead GitHub repo, etc.