Discussion: Proposal Mixes

[gilbert]

Hi all, I've just updated the wiki with the current status of all proposals so far. This thread specifically is for exploring the possibility of mixing together the two main proposals (F-sharp style and Hack style). Please visit and read that page for details.

[js-choi]

See also #75 and #84 for prior discussion on standardizing both styles’ operators.

[littledan]

Great explanation there! The only other thing I'd like to see is a summary about how these are or aren't "forward-compatible" with @rbuckton's partial application operator, and what implications they'd have for the operator if compatible. It's OK if we decide that that's not a goal, but I'd like to be explicit about the tradeoff.

[pygy]

@gilbert thanks for the summary.

I'm surprised by the presence of await on its own line, I thought that |> await was meant to act as a composite binary operator of sorts. If I understand the current proposal, they could be moved to the line above without harm in all samples:

  |> (a => readDB(a, config))
  |> await

becomes

  |> await (a => readDB(a, config))

etc...

Do you mind if I add the #23 (comment) precedence proposal as a fifth option ("F# with lower precedence")?

[gilbert]

@littledan Sure, I added some bullets indicating compatibility.

@pygy For F-sharp style, |> await f was not chosen for two reasons: it behaves differently than |> (await f), and it presents an ASI hazard. Requiring it on its own line solves both these problems.

For the grammar point I think we should wait for an approval on its possibility from a tc member first. If approved, it would impact F-sharp usage sections instead of being a 5th option.

[pygy]

@gilbert thanks, I'm catching up... The master branch still has |> await f. I see #85/#83 now.

[js-choi]

Does this issue cover both the dual-operator Proposal 3: Split Mix and the single-operator Proposal 4: Smart Mix?

Because as far as I can tell, #75 already covers Proposal 4. The original post proposes a single pipeline operator that supports both F#-style tacit calling and Hack-style placeholder expressions.

[mAAdhaTTah]

@js-choi The conversation in #75 has bounced around quite a bit. With some concrete proposals to work off of, I think we should pick up both "mix" options here and close #75.

---

I really like "Smart Mix" with some bikeshedding over the token. Seems like a solid best of both worlds. Are dropping the closing-over behavior discussed elsewhere? I think it's simpler without it, but just want to make sure that wasn't overlooked.

[littledan]

I like the Smart Mix option as well. I want to suggest a specific version of it, inspired by comments from @rbuckton:

• Use ? as the placeholder, matching partial application
• Include the await patch Spec |> await #85 ; no special behavior for yield
• Add special support for |> .method()
• Permit the placeholder only as a top-level argument of the function call, and not more deeply in an expression

This version would be cleanly forward-compatible with the partial application proposal as it currently is. IMO unless we want to argue that partial application isn't going to happen, we should try to make placeholders explainable as them. Of course it's fair game to propose changes to partial application, but I don't really see any changes as being necessary here with the above options.

@rbuckton explained to me that, even with the partial application proposal landed, it still may make sense to support a direct semantics for pipeline placeholders, to make it so that the anonymous partially applied function unobservable (e.g., through engine-specific exception handling APIs which sometimes expose sloppy mode function identities).

What do you think?

[gilbert]

@littledan What you're suggesting is not a mix, but F-sharp behavior with partial application built-in. The hack-style behavior is gone, thus the need for |> .method(). Not saying yay or nay, just wanted to make that clear.

[mAAdhaTTah]

@littledan Does this imply that arbitrary expressions, e.g. |> 'Hello' + ? are possible on RHS? That was also one of the defining features of the Hack-style proposal.

[littledan]

@gilbert Yes, I see that it's different. Should we put it as a fifth option in the wiki?

@mAAdhaTTah No, this would be disallowed.

[zenparsing]

IMO unless we want to argue that partial application isn't going to happen, we should try to make placeholders explainable as them.

Then I think we ought to have that conversation, because the forward-compatibility constraint is leading towards a bizarre set of special-case rules that I don't think anyone wants or needs.

[gilbert]

@littledan Yes, I think it would go well as "Proposal 1b", since it's F-sharp plus some features.

To be honest I think it might be the one that works for everyone. At least, for what I think you're talking about:

// Basic Usage
x |> f         //-->  f(x)
x |> f(?)      //-->  f(x)
x |> f(? + 1)  //-->  SyntaxError
x |> f(y)      //-->  f(y)(x)

// 2+ Arity Usage
x |> f(?,10)     //-->  f(x,10)
x |> f(?,10, ?)  //-->  SyntaxError?

// Async Solution
x |> f |> await       //-->  await f(x)
x |> f |> await |> g  //-->  g(await f(x))

//
// Arbitrary Expressions Option 1 (nothing special)
//
f(x) |> (a => a.data)           //-->  f(x).data
f(x) |> (a => a['my-data'])     //-->  f(x)['my-data']
f(x) |> (a => ({ result: a }))  //-->  { result: f(x) }

//
// Arbitrary Expressions Option 2 (special casing)
//
f(x) |> .data                   //-->  f(x).data
f(x) |> ['my-data']             //-->  f(x)['my-data']
f(x) |> (a => ({ result: a }))  //-->  { result: f(x) }

//
// Arbitrary Expressions Option 3 (generic placeholder)
//
f(x) |> (?).data           //-->  f(x).data
f(x) |> (?)['my-data']     //-->  f(x).data
f(x) |> { result: (?) }    //-->  { result: f(x) }

Restricting the placeholder to function argument positions is actually useful for more than just "forward-compatibility with partial app" – it allows ? to be the token without issue, since it can no longer be mixed within an expression. In other words, no more confusion with optional chaining or nullish coalescing.

But it still would be compatible with a partial app proposal that might look something like this:

var f   = ::g(?, 10)    // apply 10
var log = ::console.log // method extraction

Not that it needs to be compatible technically, but it should be compatible semantically.