Alternate operator choices

[gabejohnson]

Opening an issue to track operator suggestions

[gabejohnson]

@isiahmeadows I know you're familiar w/ |> though it has slightly different semantics.

I also like ~> and <~.

Overloading >>> would let you have that and <<< (ala PureScript). This is probably not tenable.

[dead-claudia]

As for each of your suggestions:

• I would be okay with |>, because there's numerous other operators available for that and a very similar proposal, including :: (used by the latter) and ->.
• I'd have to say no to ~> and <~, because the latter conflicts with a<~b ↔ a < ~b, and would have 0% chance of consideration.
• Overloading >>> would likely fail because of the x >>> 0 cast to unsigned in asm.js, and operator overloading in general has been a hard sell to implementors because of performance concerns.

[dead-claudia]

Another idea I just had was this: f :> g and g <: f (i.e. dropping the first-ish character).

[JAForbes]

I think we should stick with |> and <| unless there is a really good reason not to. Simply because that syntax has already been adopted by other languages. But if there is ambiguity, I like @isiahmeadows :> <: option too.

Great write up btw @isiahmeadows in the readme.

[dead-claudia]

@JAForbes Neither <:/:> nor <|/|> conflict with anything. I was just thinking that :> and <: are easier to type on a keyboard (you don't have to reach far to the right away from all the letters to type the operator).

[charliesbot]

What about <<, like Elm does? It feels easier to type.

[gabejohnson]

@charliesbox << is already taken. It's the bitwise shift operator.

[charliesbot]

oh bummer, you're right. I guess <<< like others said will do the trick :)

[dead-claudia]

Except the other direction `>>>` is also taken.

…

On Tue, Jul 11, 2017, 09:15 Charlie ***@***.***> wrote: oh bummer, you're right. I guess <<< like others said will do the trick :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AERrBLpNOTW2GFSz7a0uHPUEh1VdSIzTks5sM3WBgaJpZM4Nuqwk> .

[tiansh]

Just have a look on other languages:

Language	Expression
Haskell	f . g
SML	f o g
F#	f >> g, f << g
Perl 6	f ∘ g (∘ is U+2218)
Java 8	((Function<T1, T2>)f).compose(g)

[tiansh]

Personally prefer a method instead of operator. Operator just making ES more and more complex.

• Function.combine
• Function.prototype.combine

Both are seems better than an operator to me.

[charliesbot]

considering that pipe is gonna be an operator for sure, I would say that composition should be an operator too just to be consistent.

My two cents.

https://github.com/gilbert/es-pipeline-operator

[JAForbes]

Yeah I agree, but I think the roll out of these things will be more successful if we stage it. That linked gitter thread covers my thoughts on this @charliesbox

[dead-claudia]

Plus, it's easier to optimize. There's a few complicating factors for transpilers specifically, though (requiring a bit more desugaring boilerplate), but it'd be nothing for engines:

• new (F :> g)(...args) is equivalent to g(new F(...args)).
• (f :> g)(...args) is equivalent to g(f(...args).
• (f :> g).length === f.length always evaluates to true provided no errors are thrown, f is not a proxy, and f.length is not a getter.

Engines could do some seriously crazy stuff with it, though, even at the bytecode level:

• Proxy argument ICs to the caller function, return ICs from the returning function
• Treat chain holistically for IC handling. (minor JIT boost)
• Inline lambdas' bytecode into the composed function at bytecode compile time, only allocating enough to produce its stack frame at creation time (mild memory savings, mild creation time savings, major JIT boost)

The thing is, with a function instead, you have to wait for the JIT to kick in to detect the last one, and engines aren't likely to want to duplicate bytecode. This makes it much harder to derive any sort of special optimization, but by making it easily statically analyzable, there's fewer moving parts involved. In addition, transpilers could do the latter if it were syntax (offering most of the benefit up front), but not if it were just a function.