State of currying-PR

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?

13 Likes

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:

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

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

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

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

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

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

Maybe some more info pops up there as well.

2 Likes

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

2 Likes

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

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.

7 Likes

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.

22 Likes

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.

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.

7 Likes

The aforementioned readability of code, at least for the (relatively numerous) supporters of the feature, would be the obvious benefit. Since using the feature would, by its design, be optional, you would not be hindered in continuing to write your code in your preferred style.

Yep, this isn’t going anywhere. When it comes to currying or piping, there’s always massive threads with people arguing over everything, and in the end nothing happens. People want such a feature, but there’s no consensus. Do we at least agree that currently the |> operator is underpowered? Probably not.

1 Like

There’s a lot of support for the syntax in vague concept, but every time a concrete proposal gains some momentum, all those very same people who are so eager for the feature end up killing it by each proposing their own pet variations. We tried at some point to add the relatively uncontroversial ā€œargless lambda syntaxā€ eg -> _[_] but that too was killed off by some people insisting that multiple instances of _ should all refer to the same argument rather than different ones for each occurrence. Never mind that this makes the construct far less useful and general, but this is the pattern: we start getting somewhere and then everyone and their uncle chimes in with different opinions about the details and that kills the momentum and we get nothing.

9 Likes

You make a valid point, but I think that if the proposal had some merit, it would go through, no matter how many random comments it gets. At the end of the day, the Julia devs have the power to decide.

I think it has been going in circles because it ends up adding very little to the language from a general perspective: we are talking about saving a few characters compared to closures. Meh.

For me, the fact that this PR has stalled is a sign of how healthy the mindset of the core devs is when it comes to language design. I have always been suspicious of languages that focus on syntactic bells and whistles. Julia never had this fixation with magical syntax for various special cases, and it is great that it is kept that way.

12 Likes