Tweaking the Hack (placeholder) Syntax

[aadamsx]

@js-choi @tabatkins @mAAdhaTTah is it possible to tweak the unary function call syntax a bit, so that we don't actually need the placeholder?

For example:

value |> foo(^) // unary function calls could be written this way
value |> foo // or for unary function calls (and only unary function calls) without ^ placeholder, the compiler will assume placeholder position

value |> ^.foo() // method calls
value |> ^.foo // instead the () are not required

value |> foo |> ^.bar() // another example

etc.

[mAAdhaTTah]

Copying my comment here. I will also mark our convo on the other thread as off-topic. (Edit: I see you deleted your original comment. I can delete our comments on that thread as well to keep it clean.)

@aadamsx I believe that's effectively Smart Mix. I will mention that Smart Mix only allowed no parens in "bare style", e.g. x |> f |> a.b etc. w/ no placeholder. I think your examples would be confusing in that x |> ^.foo becoming a method call would mean you could no longer use it for property access. Smart Mix was initially proposed & discussed in #100, which also includes links to other related issues if you'd like to explore further.

[aadamsx]

I think your examples would be confusing in that x |> ^.foo becoming a method call would mean you could no longer use it for property access.

Fair enough, so in that case

value |> ^.foo() // method calls, the () are required.

But what about the first example:

value |> foo(^) // VALID: unary function calls could be written this way
value |> foo // ALSO VALID: or for unary function calls (and only unary function calls) without ^ placeholder, the compiler will assume placeholder position

value |> foo |> ^.bar() |> fooBar(^) |> yetAnotherFooBar(1, ^) // VALID syntax, where foo & fooBar are unary functions

Can't we compromise on this (optional) syntax?

[ljharb]

You’re suggesting pipe always be in “Hack mode”, placeholder required, unless the thing in the pipeline is a bare identifier, without a placeholder (when it would be in “F# mode”)?

[mAAdhaTTah]

Yeah, this is Smart Mix. My issues with it were as follows:

1. I'm not really sure "bare style" is actually that useful. While yes, it'll accept unary functions as bare identifiers, it won't accept inline composition into a unary function, meaning 1 |> multiply(2) |> add(2) is invalid, so you'd have to extract them to bare identifiers to use them in a pipeline.
2. If you think already think Hack/placeholder style is overly complicated, this compounds the problem by then changing modes depending on the presence of the placeholder. Making the placeholder-less version more expansive to be useful (addressing 1 above) would expand the associated complexity.

[aadamsx]

@ljharb @mAAdhaTTah no modes, all Hack (we never leave Hack), just the compiler will assume placeholder position only for unary functions if no placeholder is given.

Seems like a reasonable compromise to me.

[ljharb]

“unary” isn’t a characteristic that can be known at parse time or statically.

[aadamsx]

“unary” isn’t a characteristic that can be known at parse time or statically.

Think of it in reverse, the compiler will assume unary at parse time if there is no ^ placeholder.

[tabatkins]

Yeah, this is precisely the Smart Mix syntax that failed to gain traction, and got a good amount of unofficial but strong pushback from committee members. Committee members were really against the syntax having multiple interpretation modes, complaining that it was a source of confusion and likely bugs. (Several comments in this thread already provide details/context on this.)

I originally supported Smart Mix as well, but it turns out that a large amount of the code samples people have provided of pipe() in action aren't compatible with this anyway - predefined unary functions appear to be a minority case in pipe() in most contexts, overwhelmed by functions that take arguments and just return an unary function.

So, unless things significantly change in the greater committee (outside of the champion group reading this repo), which doesn't seem likely, this direction is already closed down as an option. I'm going to go ahead and close this issue.

[aadamsx]

Committee members were really against the syntax having multiple interpretation modes

No modes here, think of it as short-hand for one use case in Hack style syntax.

Committee members were really against the syntax having multiple interpretation modes, complaining that it was a source of confusion and likely bugs.

What a shame. It's too bad we can't be trusted with nice things.

predefined unary functions appear to be a minority case in pipe() in most contexts, overwhelmed by functions that take arguments and just return an unary function.

Good to know, but beside the point I think.

I originally supported Smart Mix as well

Glad to hear, this is a reasonable approach after all.

Several comments in this thread already provide details/context on this.

I'll try to find the details, thanks.