Using @ symbol instead

[trustedtomato]

@ symbol would be a logical symbol to do function composing, since the general way to read it is at, so double @ square @ minusOne would be read out like double at square at minusOne which is logically x => double(square(minusOne(x))). The opposite would be @> so the previous example would look like minusOne @> square @> double. What are your thoughts?

[TheNavigateur]

I've never read function composition as "at". If anything, I've read it as "to". Other thoughts are welcome

[trustedtomato]

"to" is logical when the direction is @>. The other direction is common in functional languages. I think +> is too similar to |>, and its two characters, which I dislike.

[TheNavigateur]

This proposal only has "forward" order direction, discussed here: https://github.com/TheNavigateur/proposal-pipeline-operator-for-function-composition/issues/4

|> hasn't been accepted in the language yet, so the point you make potentially goes both ways. Personally I think the shapes are immediately distinguishable from each other. And I don't think that @> is more descriptive than +>, if not less.

I don't think there is a single valid character that conveys the meaning and direction, but if there is then obviously that would be good

[TheNavigateur]

Ok, I'm closing this issue simply on the basis that the "at" indication of @ is predicated upon the composition being in reverse execution order, i.e. double(square(minusOne(x))) being expressed as double @ square @ minusOne, whereas this proposal is only for composition in forward execution order, for which @> was described as a derived, and not necessarily preferred, operator.

[MiracleBlue]

While I don't intend to start bikeshedding, I would like to just add some information that may or may not be of interest.

The Purescript language has what I would consider to be the best operator for composition I've seen so far. It's written as >>> for right-associated composition, and <<< for left-associated. If I were to imagine it in JavaScript, an example might look like:

const findSomething = curry((searchText, haystack) => haystack.contains(searchText) && haystack);
const splitWords = (original) => original.split(' ');
const getLength = (value) => (typeof value.length !== 'undefined' && value.length) || 0;
const sum = curry((first, last) => first + last);

const processValue = (
    findSomething('amazing') >>> splitWords >>> map(getLength) >>> reduce(sum, 0)
);

console.log(processValue('hey there folks its amazing what modern technology can do these days'))

I'm not sure if there are technical or practical limitations there might be if this operator were to be considered, I just wanted to give my 1.5¢ on this. Feel free to ignore if it's not worth investigating :)

[bathos]

@MiracleBlue >>> is already an operator in JavaScript. it performs a bitwise right shift (as if its left operand were a 32 bit signed integer) with zero-filling from the left:

assert(-1 >>> 1 === 0b01111111111111111111111111111111);