State of currying-PR

Internals & Design
1

I have found this PR from years ago:
https://github.com/JuliaLang/julia/pull/24990

I would love this feature, and I am not alone. Does anyone have a status/summary on this? The discussion is too technical at several points for me to follow.

It seems like perfect is being the enemy of the good, and that is such a shame for such a highly-requested feature. Would it be possible to reach a consensus based on some type of voting?

12 Likes
2

I also cannot speak for all the technical language discussions in that PR but as a user i would love that feature too. So IMHO this would enhance my programming experience in Julia. :slightly_smiling_face:

3

The end of the discussion mentions a test PR by Simeon (https://github.com/JuliaLang/julia/pull/40860). So, work is being done but it looks like this functionality would break many packages

4

The original version of the functionality in the PR (a Scala-like ā€œtight-bindingā€ syntax) was not breaking because it did not change the AST (and it only affected code that is currently an error).

The thing that is breaking is to try to implement a more expansive binding of the underscore by inserting new AST nodes.

6 Likes
5

Iā€™m definitely in favor of the PR in its original version. Then maybe in 2.0 we can get rid of the special currying methods for >, ==, startswith, etc.

1 Like
6

Came also across this PR the other day. Certainly a feature I would love to see. More so since the base R pipe which has been added in R 4.1 will supposedly support an underscore operator with the same functionality in R 4.2 (would be neat to have roughly the same base piping functionalities in both languages without extra packages).

4 Likes
7

Do you have a link for this? It would be nice to see what semantics they chose.

8

I was looking for it, but couldnā€™t find it (but I also have heard, and not read about it iirc). I spent some more time checking and so far no changes to the pipe implementation have been made in 4.2 dev if I can tell correctly (usually I am not that deep into language internals). https://github.com/r-devel/r-svn/blob/master/src/main/gram.c

Edit: Also on svn https://svn.r-project.org/R/trunk/src/main/gram.c

If I get any details on this I surely will remember to post them here though.

1 Like
9

Maybe some more info pops up there as well.

2 Likes
10

if itā€™s breaking then maybe that PR should get a 2.0 milestone? would love to have this feature too.

1 Like
11

It seems R has settled on a placeholder implementation for the new Base.Pipe (leaving this here because i promised earlier):

and

Maybe the folks who have discussed the related Julia PR find this useful?

4 Likes
12

Is there still interest in this? Since it was removed from the 1.x milestone 9 days ago.

I think itā€™d be an absolutely fantastic feature, improving readability and elegance of code. To me personally, itā€™s also a big step towards julia really feeling like a functional language.

5 Likes
13

Itā€™s hard to work on it without getting clear buy-in from the core devs on the semantics.

Personally, I favor the Scala-like ā€œtight-bindingā€ semantics of the original PR, which is backwards-compatible, simple to explain and reason about, and gives clear improvements in simple cases (while for everything else you can use ->).

Every attempt to devise a more expansive DWIM syntax (to handle compound expressions like 1 + 2_) led to confusion, breakage, and ultimately ground progress to a halt.

20 Likes
14

I feel like the ā€œ\bullet instead of _ā€ idea from RFC: curry underscore arguments to create anonymous functions by stevengj Ā· Pull Request #24990 Ā· JuliaLang/julia Ā· GitHub didnā€™t get enough attention.

If _ is too issue prone and \bullet doesnā€™t cause these issues, which I donā€™t know if it does, it should be worth a look. In my experience most would agree that readability of code is a great objective, far more important than typing a bit less, and this could bring julia code a lot closer to concise math notation at possibly no cost.

15

Personally, Iā€™m pretty sure Iā€™d prefer that no feature like this gets accepted. It would complicate the language, and I, for one, donā€™t see any benefit. Lately Iā€™ve even stopped using anonymous functions, preferring to always give closures a name, to achieve a better debugging experience and better error messages. Furthermore, having a multi-line method definition allows for more granular code coverage.

3 Likes