Lambdas: |args| syntax should facilitate manually-curried functions.

[bblum]

I brought up manually-currying functions with @eholk and @brson, and we discussed the relative merits/demerits of the new lambda syntax. I think everyone agrees that the braces shouldn't be required, so you can write stuff like:

|a||b||c| a+b+c;

Edit: NOTE: My opinion has changed from what's written below - look in the comments.

But I think it'd be better if they bound forever instead of stopping at the first semicolon. The downsides of binding forever:

• You can't write "for ... |i| { block }; after_loop();" (you have to stick with the current braces-before syntax). Personally, I like the current syntax better anyway.
• You have to use either braces or parens most of the time, like "map2((|x,y|x+y),[1,2,3],[4,5,6])".

The benefit is the following idiom for manually-curried functions.

fn zipWith<A,B,C>(f: fn(A,B) -> C) -> fn@([A]) -> fn@([B]) -> [C] {|list1||list2|
    ... apply f to list1 and list2 with multiple statements ...
}

It expresses multi-staged computation really well to boot:

fn foo(x: X) -> fn@(Y) -> fn~(Z) {
    stage0(x);
|y|
    stage1_partA(x,y);
    stage1_partB(x,y);
|z|
    stage2(x,y,z);
}

Foo does stage0, returns a @-callback which awaits y before performing stage1 and then returning a ~-callback which etc etc. If we require braces to get multi-statement lambdas, you won't be able to write this sort of thing without rightward drift.

Even apart from this 'staged' pattern, I think we should make manually currying easier. It'd be good to have curried versions of map and fold, so you could write for example "foldl(0, sum)" and hand it to someone else who has a list of numbers.

Lambdas bind forever in haskell, in SML, in all renderings of lambda calculus I've seen. Brian says they only bind one expression in C#. In C++ they require braces, so that could go either way.

Also, I suspect every functionally-seasoned programmer will trip up over lambdas not binding forever. I realise our target audience is more the C++ crowd, but that's still an issue.

[eholk]

I really like being able to write the map2 example as map2(|x, y| x + y, [1, 2, 3], [4, 5, 6]). I'm not sure the parentheses would be required here though even if lambda binds forever, since as far as I know, there's not way x + y, [1, 2, 3], [4, 5, 6] would parse as something else.

[bblum]

I'm not well-versed enough in rustic grammar to say for sure, but I think if we allow stopping at commas (at the same paren-level), we won't rule out any cases in which forever-binding could correctly parse more stuff. (That is to say, nobody should be surprised when it parses one way when it could legally have parsed another.)

It'd be good if someone could confirm that, and also perhaps mention any other stop-binding-here tokens that would be similarly unambiguous.

I'd be wary of adding too many special-cases ("Oh, and you can also write lambdas like this, if there's a comma, and also..."). I could go either way on the comma case in particular.

[eholk]

It seems to me like we are discussing the difference between the current rule, which is roughly lambda -> |args| expr, and the bind forever rule, which is lambda -> |args| ( expr ; )* expr. As long as we don't also have a rule like C's comma sequence operator (roughly expr -> stmt, expr), then I don't think there's any difficulty in parsing something like map2(|x, y| let z = x + y; z, [1, 2, 3], [4, 5, 6]). However, having semicolons in argument lists seems pretty terrible to me...

Bind forever has problems in cases like this:

let x = |z| io::println(z);
let x = 5;

Under the current rule, this first sets x to a function that just prints its argument, and then rebinds x to 5. Under bind forever, this binds x to a function that prints its argument and then internally creates a new x that is bound to 5. I'm not really sure how to end the outermost let expression now.

I think the bind forever rule leads to things like this too:

fn foo() {
   let mut total = 0;
   for int::range(0, 4) |i| total += i;
   log(error, total);
}

With bind forever, we end up printing 0, then 1, then 3, then 6, instead of just printing 6. I'd be surprised if this is ever what a Rust programmer wants.

[bblum]

Hm, that is indeed a problem, but I think a solvable one. We could make the compiler warn on such uses, printing out "did you mean (|i| total += i;)?"

How to get the compiler to decide not to warn, in a way not dependent on whitespace (looking for newlines, etc) is still in the air. Maybe there's a grammar-level distinction between the use examples I provided and the ones you said - like "in the middle of a statement instead of at the start of a new binding group"?

[bblum]

Changed the title. I realised that how far lambda binds is sort of a red herring, and really what I care about is being able to easily write curried functions. I now have another proposal which I think solves every problem, even the "manually currying requires writing the variable name far away from its type" one.

Lambdas bind one expression, until a semicolon or comma. (It turns out SML stops binding at semicolons too. No big loss) So for (..) |i| { .. } is the loop syntax, as people seem to want. But, to avoid drowning in braces when currying, we also add syntax sugar:

fn foo(x: X)@(y: y)~(z: Z) {
    body
}

expands to

fn foo(x: X) -> fn@(Y) -> fn~(Z) {|y||z|{
    body
}}

(Maybe default to @, so you can write fn foo(x: X)(y: Y)~(z: Z). Not sure.)

The only downside of this (apart from opposing my aesthetic preference for the current loop syntax over the new loop syntax, which I'm prepared to part with) is that the "staged computation" stuff is lost, and has to be written without sugar - maybe it was just a curiosity to begin with, or maybe we could come up with extra sugar/macros for that.

[bblum]

The syntax could further generalise to writing function types, not just function declarations. Consider a zipWith that takes a curryable function as an argument:

fn zipWith(f: fn(A)@(B) -> C) @(list1: [A]) @(list2: [B]) -> [C] {

Or even, if we default to @,

fn zipWith(f: fn(A)(B) -> C) (list1: [A]) (list2: [B]) -> [C] {

I'm playing fast-and-loose with the vector type syntax here, but the more I look at this, the more I like it.

[bblum]

Dunno about this one's feasibility, since the new closure syntax has been in for a while. I care less about it, to be sure.