Compact closure args

[jfager]

How is this ‘magic’? It’s just taking closure args via a different means.

[nathantypanski]

I don’t know what _ in a closure means. I guess it’s an implicit default variable (doesn’t Perl do something like this?). But then what happens with multiple arguments? It’s not at all obvious. There’s no natural way to extend that, because there’s a magic variable that has behavior you have to memorize before using.

With the | syntax it’s slightly more keypresses, but variable definitions work mostly the same way as in functions (bar not having to annotate types): You list the arguments, and you put commas between them. If I see a closure and it has |x| and I want to add another argument to it, nobody has to explain to me to do try |x, y|: it’s just the natural thing to do. No, I have not written Ruby before (I program for scientists, and thus favor Python).

Perhaps you could make a slightly stronger case for $narg. But then you lose out on both (1) knowing exactly how many arguments you have and (2) being able to annotate the types of your arguments.

If your case is going to be “this is equally/less implicit/magic than the current syntax” I think you will find it hard to make that point.

[jfager]

Ok, yeah, _ in Scala is mysterious for multiple args, which is why I said I personally don’t like it. I’m primarily referring to the $n syntax, which doesn’t strike me as magic, just different; I only mentioned the others on the off chance people would be more receptive to aping prior art.

This is only intended for closure args, not free closures, so you know how many arguments you have via the caller, statically enforced by the compiler. If you want to annotate the types of your arguments, just use the regular syntax; this is sugar only.

[Drup]

(Cf http://discuss.rust-lang.org/t/auto-currying-in-rust/149/18)

[theypsilon]

Maybe you can use “|n” as an expression for not wasting any other symbol, because “|” is already associated to closures, but a numeric literal following “|” would not have any ambiguity. I think that syntax would also be interesting for nested lambda-expressions. Consider this ridiculously absurd example:

map( |0.filter( ||0.getNumber() != |0.getForbiddenNumber() ) )

[huon]

How is it known what should be closurefied?

Edge cases:

• map(foo($0 + 1)): is it |x| map(foo(x + 1)), map(|x| foo(x + 1)), map(foo(|x| x + 1)) or map(foo((|x| x) + 1))?
• something(some_iter.all($0)), is that something(|x| some_iter.all(x)) or something(some_iter.all(|x| x))
• let a = { let b = $0 + 1; ... }, is it let a = |x| { let b = x + 1; ... } or let a = { let b = |x| x + 1; ... }

Basically, as soon as you have nested expresions (which is every Rust program ever), there needs to be a rule for what expressions are in the closure and what are not.

[jfager]

Sure, you’d just make a rule. ‘Tightest fn that requires a closure arg’ seems reasonable. So for your cases:

• map(foo($0 + 1)) is map(foo(|x| x+1)) if foo takes a closure arg; map(|x| foo(x + 1)) if it doesn’t.
• something(some_iter.all($0)) is something(some_iter.all(|x| x))
• let a = { let b = $0 + 1; ... } isn’t allowed b/c it’s not a closure in arg position.

I think you’re overstating the frequency that this would be ambiguous or confusing; nested expressions are common but fns that takes closure args that take closure args are not.

The cases that benefit the most are chained transforms. Something like

foo.iter().map(|x| x.bar).filter(|x| x > 0).collect()

becomes

foo.iter().map($0.bar).filter($0 > 0).collect()

In the single-arg case, the Scala syntax is even nicer:

foo.iter().map(_.bar).filter(_ > 0).collect()

but it falls apart with multiple args. I’d be happy with only making the sugar available for single-arg closures, as well, which would make the feature simpler while still covering a lot of use cases.

[huon]

‘Tightest fn that requires a closure arg’ seems reasonable

I’m not sure if introducing name resolution & type checking into choosing how a syntactic construct is ‘defined’ is a good idea. Maybe it’s not such a problem in practice, but it is certainly magical, since you can’t tell what’s going on without checking type signatures, and even trait implementors, e.g. the map(foo(...)) example could have foo<T: SomeTrait>(...) and then behaviour would differ based on if any closure types implement SomeTrait.

[jfager]

Rust already requires you to check signatures to figure out what’s happening in a lot of cases, because of type inference. And isn’t, for instance, ‘a + b’ a syntactic construct that’s defined in terms of name resolution and type checking? I’m not a compiler writer so the distinction isn’t immediately clear to me.

[benh]

As far as I can tell it’d be the only place in the grammar where you need to do typechecking to know how to parenthesize an expression, eg. how to build the ast.

[huon]

And isn’t, for instance, ‘a + b’ a syntactic construct that’s defined in terms of name resolution and type checking?

This would be the only dependence on type signatures for control flow, i.e. when each of foo, bar and baz are executed in foo(bar(baz($0 + 1))) changes based on the precise type signatures of those functions.

[glaebhoerl]

For the record it seems Scala doesn’t avoid this issue either.

The suggestion in that comment is to have a separate marker to introduce the lambda, which, while slightly reducing compactness, doesn’t seem unreasonable.

E.g., just as a strawman to illustrate, if we use @ to introduce “compact closures”, and _ for implicit arguments:

foo(@bar(_ + 1))

would be the equivalent of:

foo(|x| bar(x + 1))

(Again, this is not a proposal - just a demonstration.)

[glaebhoerl]

One particular tactic which doesn’t seem like it would be horrible would be to use the same symbol both to introduce the lambda and then as a sigil for its positional arguments.

There are four reasonable possibilities I can think of for this symbol, each with different potential conflicts.

Each of the below examples is equivalent to: sort_by(|x0, x1| foo(x0) > foo(x1))

• sort_by(@ foo(@0) > foo(@1))

This likely conflicts with e.g. the proposed use of @ for attributes (but there are many potential uses for @).

• sort_by($ foo($0) > foo($1))

This likely conflicts with macros. (I’m not super familiar with macros but I know they use $.)

• sort_by(? foo(?0) > foo(?1))

This likely conflicts with the proposed postfix ? for exception propagation.

• sort_by(\ foo(\0) > foo(\1))

This likely conflicts with the idea of a \foo b for infix function calls.

Potentially (at least for some of these) we could also allow just the sigil without a number, or _, in which case the numbering would be implicit based on the order they appear in the code. (Probably the two would be mutually exclusive, i.e. either all arguments have to be numbered or none.) EDIT: Actually this would likely be ambiguous with the very idea of using the sigil to introduce the lambda… but _ would still be OK. (Unless we use that for default arguments or something.)

[glaebhoerl]

Of course, we could just take the KISS route, which would most likely be the best one, and define simple mechanical rules about the scoping of implicit closures. For instance:

The scope of an implicit closure extends to EITHER

• the innermost function or method call,

OR

• the innermost expression consisting of only unary and binary operators

whichever comes first, with a placeholder _ in place of one or more subexpressions. This translates to a lambda with a number of arguments equal to the number of placeholders, which are substituted in their place left-to-right.

And if you want to do anything more complicated, write an explicit lambda.

Some examples of how the above would work:

• foo(f(x, _)) => foo(|a| f(x, a))

• foo(_.f(x, y)) => foo(|a| a.f(x, y))

• foo(x + _ + z) => foo(|a| x + a + z)

• foo(f(_, g(x))) => foo(|a| f(a, g(x)))

• foo(f(x, g(_))) => foo(f(x, |a| g(a)))

• foo(f(_, g(_))) => foo(|a| f(a, |b| g(b)))

• foo(f(_, _)) => foo(|a, b| f(a, b))

• foo(x * _ + _) => foo(|a, b| x * a + b)

• foo(f(x, _ * y + z)) => foo(f(x, |a| a * y + z))

• foo(f(x) * _ + z) => foo(|a| f(x) * a + z))

• foo(f(_) * y + z) => foo((|a| f(a)) * y + z)

• foo(f(_) * _ + z) => foo(|a| (|b| f(b)) * a + z)

And so on. And if that’s not what you wanted, the typechecker will let you know.

(Maybe not these exact rules; these are just the first I thought of. But the point is to keep them simple, predictable, and mechanical.)

[Gonzih]

I personally prefer explicit syntax more. It feels like being explicit is The Rust Way. So I don’t see a lot of gain from change like that.

[gsingh93]

I didn’t know you could do that. I really like this syntax, but it works out nicer in Python where you don’t have to worry about passing references or values. A common case (for me) is passing in the first parameter by value (like an i32, for example). In this case, this syntax fails. So I can’t do simple things like let v2: Vec<i32> = v.iter().map(double).collect() (where double doubles an element) without modifying the double function itself. Really annoying.

[seanmonstar]

You can add a deref map into your iter line. v.iter().map(|i| *i).map(double)...

[gsingh93]

Yea, but that at that point I might as well write v.iter().map(|i| double(*i)).collect().

[tbu]

v.iter().cloned().map(double).collect()

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.