State of currying-PR

TheLateKronos · November 22, 2021, 8:24am

I have found this PR from years ago:

github.com/JuliaLang/julia

RFC: curry underscore arguments to create anonymous functions

JuliaLang:master ← stevengj:curry

opened 07:10PM - 08 Dec 17 UTC

stevengj

+72 -6

This PR addresses #554, #5571, and #22710 by "currying" underscores in function …calls like `f(_,y)` into anonymous function expressions `x -> f(x,y)`. (Note that `_.foo` works and turns into `x -> x.foo` since it is equivalent to a `getfield` call, and `_[i]` works and turns into `x -> x[i]`, since it is equivalent to a `getindex(_,i)` call.) This will help us get rid of functions like `equalto` (#23812) or `occursin` (#24967), is useful for "destructuring" as discussed in #22710, and should generally be convenient in lots of cases to avoid having to explicitly do `x -> f(x,y)`. Some simplifying design decisions that I made: * The currying is "tight", i.e. it only converts the immediately surrounding function call into a lambda, [as suggested by](https://github.com/JuliaLang/julia/issues/22710#issuecomment-314259250) @JeffBezanson (and [as in Scala](https://www.scala-lang.org/files/archive/spec/2.11/06-expressions.html#placeholder-syntax-for-anonymous-functions)). So, e.g. `f(g(_,y))` is equivalent to `f(x -> g(x,y))`. (Note that something like `find(!(_ in c), y)` will work fine, because the `!` operator works on functions; you can also use `_ ∉ c`.) Any other rule seems hard to make comprehensible and consistent. * ~~Only a single underscore is allowed. `f(_,_)` throws an error: this case seems ambiguous to me (do you want `x -> f(x,x)` or `x,y -> f(x,y)`?), so it seemed better to punt on this for now. We can always add a meaning for multiple underscores later.~~ Similar to Scala, multiple underscores are converted into multiple arguments in the order they appear. e.g. `f(_,y,_)` is equivalent to `(x,z) -> f(x,y,z)`. See [rationale below](https://github.com/JuliaLang/julia/pull/24990#issuecomment-350879561). The implementation is pretty trivial. If people are in favor, I will add - [x] Tests - [x] Documentation - [ ] Fix interaction with broadcasting `f.(x, _)` - [ ] Fix interaction with keyword arguments `f(x; y=_)` - [ ] Support chained comparisons, e.g. `3 ≤ _ ≤ 10`, since they parse as a single expression?

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?

DoktorMike · November 22, 2021, 7:54pm

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.

rikh · November 22, 2021, 10:24pm

The end of the discussion mentions a test PR by Simeon (test parser support for underscore curry by simeonschaub · Pull Request #40860 · JuliaLang/julia · GitHub). So, work is being done but it looks like this functionality would break many packages

stevengj · November 22, 2021, 11:11pm

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.

CameronBieganek · November 22, 2021, 11:20pm

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.

DorianT · November 23, 2021, 12:26am

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).

stevengj · November 23, 2021, 1:43am

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

DorianT · November 23, 2021, 1:33pm

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). r-svn/gram.c at master · r-devel/r-svn · GitHub

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.

DorianT · November 27, 2021, 3:35pm

Maybe some more info pops up there as well.

bjarthur · November 29, 2021, 3:31am

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

DorianT · March 10, 2022, 6:55pm

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?

boogiewoogie · March 22, 2022, 5:16pm

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.

stevengj · March 22, 2022, 8:43pm

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.