interesting. Can you expand on Elixir incompatibility? How is it different?
Elixir does: Enum.map(list, func) This is backwards to how partial application works: def mapper(func), do: Enum.map(func) incrementer = mapper(fn x -> x + 1 end) incrementer(list) It's not the end of the world to not have it this way, but it removes a lot of patterns that are common in other functional languages.
It doesn't remove or break anything, it just changes the order of arguments to be compatible with Elixir's (|>) operator and consistent data-first design across the language.
Elixir does: Enum.map(list, func) This is backwards to how partial application works: def mapper(func), do: Enum.map(func) incrementer = mapper(fn x -> x + 1 end) incrementer(list) It's not the end of the world to not have it this way, but it removes a lot of patterns that are common in other functional languages.
It doesn't remove or break anything, it just changes the order of arguments to be compatible with Elixir's (|>) operator and consistent data-first design across the language.
Definitely, I missed to mention that partial application via currying isn't something you do in Erlang either.
If you did however, swapping the arguments would break most partial application patterns you see in languages like Haskell, OCaml, Elm and even JS.
It doesn't remove or break anything, it just changes the order of arguments to be compatible with Elixir's (|>) operator and consistent data-first design across the language.
Definitely, I missed to mention that partial application via currying isn't something you do in Erlang either. If you did however, swapping the arguments would break most partial application patterns you see in languages like Haskell, OCaml, Elm and even JS.
yeah but at this point, currying seems to be a loss in ergonomics in most use case we have found in the wild. I love the idea, I love the principle.
But the jury is definitely still out for if the pattern of showing it in syntax and semantics actually is beneficial. And yes, I know nearly all the examples you can come with to show how useful it can be.
But the cost of having it seems to more than compensate the benefits.
> ...by the time x.len() gets executed, arg0 already exists... So, I realize that this is the way that Java does it--and, presumably, one still doesn't get fired for doing whatever Java does ;P--but, would it not actually make more sense for the arguments to be evaluated before the target reference, making the argument order more like Haskell/Erlang (but very sadly not Elixir, which makes it awkwardly incompatible wi…
Doesn't Rust support having a function as a field of a struct?
If it does, then the order of evaluation of a.foo(b) would depend on whether foo is a field or a "free-standing" function of a, which seems horrible.
Also, there is a simple elegance in having the order of evaluation match the order the symbols are written that should require a very hight bar to reverse, in my opinion at least.
It doesn't remove or break anything, it just changes the order of arguments to be compatible with Elixir's (|>) operator and consistent data-first design across the language.
Definitely, I missed to mention that partial application via currying isn't something you do in Erlang either. If you did however, swapping the arguments would break most partial application patterns you see in languages like Haskell, OCaml, Elm and even JS.
I do partial application in Elixir all the time. I have a function `curry/1` which takes any function and gives a curried version of it, and I have a `p` macro which introduces Scala-like "holes" (e.g. `(p Enum.map(list, _))`). The order of arguments still doesn't matter and nothing is broken or impossible because of it. I have also tweaked the (|>) macro (as well as some other operators) to support holes, so that I can "pipe" into whichever position of the call.
I think there are many more severe problems with Elixir which make it not even a remotely functional PL for me (rather, procedural + macros), but arguments order is not one of them.
> ...by the time x.len() gets executed, arg0 already exists... So, I realize that this is the way that Java does it--and, presumably, one still doesn't get fired for doing whatever Java does ;P--but, would it not actually make more sense for the arguments to be evaluated before the target reference, making the argument order more like Haskell/Erlang (but very sadly not Elixir, which makes it awkwardly incompatible wi…
Doesn't Rust support having a function as a field of a struct? If it does, then the order of evaluation of a.foo(b) would depend on whether foo is a field or a "free-standing" function of a, which seems horrible. Also, there is a simple elegance in having the order of evaluation match the order the symbols are written that should require a very hight bar to reverse, in my opinion at least.
It does, but Rust also has separate namespaces for methods and variables. That is, a.foo(b) will always be a method foo and never a field foo, because the syntax is that of a method. In order to access a function object, then call it, you would use (a.foo)(b). The parentheses cause the contents to be parsed as a variable expression.
Definitely, I missed to mention that partial application via currying isn't something you do in Erlang either. If you did however, swapping the arguments would break most partial application patterns you see in languages like Haskell, OCaml, Elm and even JS.
I do partial application in Elixir all the time. I have a function `curry/1` which takes any function and gives a curried version of it, and I have a `p` macro which introduces Scala-like "holes" (e.g. `(p Enum.map(list, _))`). The order of arguments still doesn't matter and nothing is broken or impossible because of it. I have also tweaked the (|>) macro (as well as some other operators) to support holes, so that I…
I applaud your efforts, but that is a lot of work against the grain. I've yet to see a curried function in the wild outside of a handful of anonymous functions passed as HoFs.
> I think there are many more severe problems with Elixir ... but arguments order is not one of them.
Cheers, I have no dog in this game, merely expanding on what (I think) OP was alluding to.
Definitely, I missed to mention that partial application via currying isn't something you do in Erlang either. If you did however, swapping the arguments would break most partial application patterns you see in languages like Haskell, OCaml, Elm and even JS.
yeah but at this point, currying seems to be a loss in ergonomics in most use case we have found in the wild. I love the idea, I love the principle. But the jury is definitely still out for if the pattern of showing it in syntax and semantics actually is beneficial. And yes, I know nearly all the examples you can come with to show how useful it can be. But the cost of having it seems to more than compensate the benef…
I'm not necessarily a proponent of currying; merely wanted to expand on what OP was pointing at.
The reason I like Erlang is because of the BEAM (+ OTP) combined with idiomatic pattern matching, I don't miss currying in neither language.
I do partial application in Elixir all the time. I have a function `curry/1` which takes any function and gives a curried version of it, and I have a `p` macro which introduces Scala-like "holes" (e.g. `(p Enum.map(list, _))`). The order of arguments still doesn't matter and nothing is broken or impossible because of it. I have also tweaked the (|>) macro (as well as some other operators) to support holes, so that I…
I applaud your efforts, but that is a lot of work against the grain. I've yet to see a curried function in the wild outside of a handful of anonymous functions passed as HoFs. > I think there are many more severe problems with Elixir ... but arguments order is not one of them. Cheers, I have no dog in this game, merely expanding on what (I think) OP was alluding to.
It's definitely against the grain but also not really a lot of work. The currying function is ~3-4 lines. The macros are 5-10 lines each. As for examples of such things being used "in the wild", many use Witchcraft library which strives to give a Haskell-like experience to Elixir.