24 ms·

But the syntax adds a layer of obfuscation over the mechanics of currying. I thought we were getting somewhere with Elm, Purescript, and Reason adopting it and

by bjz_ 9y ago

But the syntax adds a layer of obfuscation over the mechanics of currying. I thought we were getting somewhere with Elm, Purescript, and Reason adopting it and making it more widely known, but then we've gone a step backward again. I kind of feel like we need better communication and education rather than just doing a band-aid fix that only helps folks in the short term. :( Did you consider having a 'beginner mode' Reason, then flipping a switch to compare it to compare it to the non-parened version is?

chenglou 9y ago
I'm gonna argue beside the point, but currying has negative semantics and type system impact in a language with uncontrolled side-effects. It also prevents some optimizations and new type features. Don't take my words for it: https://github.com/facebook/reason/pull/1299#issuecomment-309032848 https://github.com/facebook/reason/pull/1299#issuecomment-30... https://realworldocaml.org/v1/en/html/imperative-programming-1.html#side-effects-and-weak-polymorphism https://realworldocaml.org/v1/en/html/imperative-programming... https://drup.github.io/2016/08/02/difflists/ https://drup.github.io/2016/08/02/difflists/ https://bucklescript.github.io/bucklescript/Manual.html#_callback_optimization https://bucklescript.github.io/bucklescript/Manual.html#_cal... I'm jumping into this conversation early on because too often this point is raised and turns into an uncharitable interpretation of our motivations, e.g. "look at these js programmers, not understanding the beauty of currying". Rest assured that we do (and that we're not just js programmers), and that the Merlin and BuckleScript authors know very well what they're doing. Hope this clarifies things a bit.
- bjz_ 9y ago
  I'm not talking about you not knowing, I'm more worried about language designers talking down to programmers for short term gains, rather than trying to raise them up with tools that will benefit them in the long term. Interesting about argument syntax + effects. I've mainly used currying in pure languages. Is it about accidentally calling an effectful function multiple times? Is the idea here that you are conservatively treating everything as effectful with the uncurried syntax (before algebraic effects land), then will make pure stuff curried in order to attract people to use pure functions where possible?
  - yawaramin 9y ago
    There's a distinction between syntax and semantics though. E.g. Go pushes bad semantics (null values, bad error handling, no generics) in the name of beginner ease, with no transition path to better semantics. Reason pushes 'bad' (JavaScript) syntax but good OCaml semantics in the name of attracting JavaScript devs, with a clear transition path to OCaml syntax should they want to.
    - bjz_ 9y ago
      Good points. Still weird to have a syntax that is at odds with the underlying semantics, and hopefully it doesn't sow more confusion than it initially solves in the long term. I still can't get my head around why it would be an optimization problem too, seeing as it would be most using the same underlying AST. Unless they actually translate the pseudo-parameter lists into actual tuples in the parser, forbidding raw, single argument passing. :/
      - yawaramin 9y ago
        Yes, as far as I know Reason is the first project to try to have auto-currying semantics with tupled syntax. It's definitely a bit of an experiment. Not sure what optimisation problem you're referring to, Reason and OCaml underlying AST are exactly the same. There are no actual tuples unless the programmer is creating actual tuples.
        bjz_ 9y ago
        I was referring to chenglou's comment[1] where he said "It also prevents some optimizations and new type features." [1]: https://news.ycombinator.com/item?id=15573956 https://news.ycombinator.com/item?id=15573956
        glennsl 9y ago
        I think what @chenglou was referring to are issues like the "value restriction" [1] and the need to wrap "uncurried" FFI functions with a function that "adapts" it to curried form, thereby adding a layer of indirection. Reason does not solve these, they're problems inherent to the underlying language and the choices made. I think the point being made was just that currying isn't a clear step forward, but causes some problems as well. [1]: http://mlton.org/ValueRestriction http://mlton.org/ValueRestriction
- wtetzner 9y ago
  > currying has negative semantics and type system impact in a language with uncontrolled side-effects. Can you explain this? Currying and side-effects seem orthogonal to me.

by bjz_ 9y ago

chenglou 9y ago

I'm gonna argue beside the point, but currying has negative semantics and type system impact in a language with uncontrolled side-effects. It also prevents some optimizations and new type features. Don't take my words for it: https://github.com/facebook/reason/pull/1299#issuecomment-309032848 https://github.com/facebook/reason/pull/1299#issuecomment-30... https://realworldocaml.org/v1/en/html/imperative-programming-1.html#side-effects-and-weak-polymorphism https://realworldocaml.org/v1/en/html/imperative-programming... https://drup.github.io/2016/08/02/difflists/ https://drup.github.io/2016/08/02/difflists/ https://bucklescript.github.io/bucklescript/Manual.html#_callback_optimization https://bucklescript.github.io/bucklescript/Manual.html#_cal... I'm jumping into this conversation early on because too often this point is raised and turns into an uncharitable interpretation of our motivations, e.g. "look at these js programmers, not understanding the beauty of currying". Rest assured that we do (and that we're not just js programmers), and that the Merlin and BuckleScript authors know very well what they're doing. Hope this clarifies things a bit.

bjz_ 9y ago
I'm not talking about you not knowing, I'm more worried about language designers talking down to programmers for short term gains, rather than trying to raise them up with tools that will benefit them in the long term. Interesting about argument syntax + effects. I've mainly used currying in pure languages. Is it about accidentally calling an effectful function multiple times? Is the idea here that you are conservatively treating everything as effectful with the uncurried syntax (before algebraic effects land), then will make pure stuff curried in order to attract people to use pure functions where possible?
- yawaramin 9y ago
  There's a distinction between syntax and semantics though. E.g. Go pushes bad semantics (null values, bad error handling, no generics) in the name of beginner ease, with no transition path to better semantics. Reason pushes 'bad' (JavaScript) syntax but good OCaml semantics in the name of attracting JavaScript devs, with a clear transition path to OCaml syntax should they want to.
  - bjz_ 9y ago
    Good points. Still weird to have a syntax that is at odds with the underlying semantics, and hopefully it doesn't sow more confusion than it initially solves in the long term. I still can't get my head around why it would be an optimization problem too, seeing as it would be most using the same underlying AST. Unless they actually translate the pseudo-parameter lists into actual tuples in the parser, forbidding raw, single argument passing. :/
    - yawaramin 9y ago
      Yes, as far as I know Reason is the first project to try to have auto-currying semantics with tupled syntax. It's definitely a bit of an experiment. Not sure what optimisation problem you're referring to, Reason and OCaml underlying AST are exactly the same. There are no actual tuples unless the programmer is creating actual tuples.
      - bjz_ 9y ago
        I was referring to chenglou's comment[1] where he said "It also prevents some optimizations and new type features." [1]: https://news.ycombinator.com/item?id=15573956 https://news.ycombinator.com/item?id=15573956
        glennsl 9y ago
        I think what @chenglou was referring to are issues like the "value restriction" [1] and the need to wrap "uncurried" FFI functions with a function that "adapts" it to curried form, thereby adding a layer of indirection. Reason does not solve these, they're problems inherent to the underlying language and the choices made. I think the point being made was just that currying isn't a clear step forward, but causes some problems as well. [1]: http://mlton.org/ValueRestriction http://mlton.org/ValueRestriction
wtetzner 9y ago
> currying has negative semantics and type system impact in a language with uncontrolled side-effects. Can you explain this? Currying and side-effects seem orthogonal to me.