add F#-style "pipe" operator |>

Several times in the past, users (including me!) have requested an F#-style pipe operator, which accepts any type T has the left operand, and a unary function type F(T) as the right operand.

val |> fun

would be an abbreviation for:

let (_ = val) fun(_)

Thus, you could write print("hello") as "hello" |> print.

If I’m not mistaken, |> is naturally left-associative.

I’m now favorably-disposed toward this proposal, and the syntax seems viable. It looks like it can be implemented by desugaring and need not impact the backends in the initial implementation.

An open question is: is foo |> bar considered a legal statement? Can I write this:

void hello() {
    "hello" |> print;
}

I would say that we should accept this code.

Discussion on Gitter led to me proposing two additional variations of this operator, by analogy to the existing ?. and *. operators.

• maybe ?|> fun would propagate nulls from left to right, being equivalent to if (exists _=val) then fun(_) else null
• tuple *|> fun would spread a tuple over the parameters of an arbitrary-arity function, being equivalent to let (_=val) fun(*_)

(Note that these operators could also be easily defined in terms of |> and a higher-order function. For example, tuple *|> fun is equivalent to tuple |> unflatten(fun).)

Both of these are useful—I’ve wanted something like ?|> many times when writing real Ceylon code—but the objection was raised by @someth2say that they’re too ascii-arty for this language. That’s a reasonable objection, and we should give it some weight.

Feedback?

[gavinking]

This is now working well enough that you folks can try it out, if you like. For example, the following code:

shared void run() {
    "hello world how are you today, I'm doing great !!!! xxxxxyyy"
            |> String.size
            |> (Integer i) => Integer.format(i, 16) 
            |> String.uppercased 
            |> String.trimmed 
            |> print;
}

prints 3C with both ceylon run and ceylon run-js.

[gavinking]

@FroMage My feeling is that we would introduce |> as a first step. I don’t think I would add ?|> and *|> initially, since I kinda agree with the thinking that they’re potentially cryptic.

I agree that bar(foo()) is clearer than foo() |> bar, however, I don’t think that reasoning holds when it’s

bar(foo(baz(fee(fi(fo(fum))))))

vs

fum |> fo |> fi |> fee |> baz |> foo |> bar