Suggestion: Infix operators/functions

[kdex]

People in the C++ community have been using overloaded operators since the 
1980's, and I wouldn't say that different semantics for the same operator have 
been a bad idea at all, given that the operator handles completely different 
types (that can and should be statically analyzable).

I wouldn't even think that these features are abused in the C++ community: 
Think vector/matrix operations, for instance. Very expressive stuff.

Depending on the application, it could be nicer for Array + Array to become 
Array(Array, Array) rather than Array(...Array, ...Array). Depends on your use 
case. As for function composition, it's a matter of preference if A + B is 
supposed to mean (...args) => A(B(...args)) or rather (...args) => 
B(A(...args)).

My point is, as long as there is a statically analyzable definition for how 
operators are supposed to behave for a given set of input types, there's no 
reason not to give programmers the ability to provide such definitions.

But again, these discussions will be much more relevant if proposals such as 
[this one](https://github.com/sirisian/ecmascript-types) are discussed for 
standardization at some point.

On Saturday, February 3, 2018 4:57:34 AM CET Naveen Chawla wrote:
> I don't like the idea of custom operators only because of readability of
> code - it can be different for different pieces of code, and so I think it
> is a larger surface area for bugs, so I think it would be a net negative.
> 
> However, I do like the idea of allowing e.g. `+` to be used intuitively and
> consistently (i.e. with a fixed meaning) between certain data types that
> are not currently supported, e.g.:
> 
> Array + Array (array concatenation)
> Function + Function (function composition)
> 
> On Fri, 2 Feb 2018 at 22:02 Michael Haufe <tno at thenewobjective.com> wrote:
> > How would operator precedence work? Would we be restricted to 2-argument
> > functions only?
> > 
> > On Fri, Feb 2, 2018 at 5:55 AM, Thomas Grainger <tagrain at gmail.com> wrote:
> >> I'm porting this from the TypeScript issue tracker, original from:
> >> https://github.com/Microsoft/TypeScript/issues/2319#issue-60851953
> >> 
> >> Since it's very unlikely that the extension methods will ever be
> >> implemented [in a call-site-rewrite
> >> manner](
> >> https://github.com/Microsoft/TypeScript/issues/9#issuecomment-74302592),
> >> please consider adding infix operators to enable writing in functional
> >> style similarly to what can be done in Haskell:
> >> 
> >> Monoids
> >> 
> >> ```js
> >> 
> >>     function '+' (left, right) {
> >>     
> >>        return left.concat(right);
> >>     
> >>     }
> >>     
> >>     [1, 2, 3] '+' [4, 5]; // [1, 2, 3, 4, 5]
> >> 
> >> ```
> >> 
> >> Monads
> >> 
> >> ```js
> >> 
> >>     function '>>=' (promise, bind) {
> >>     
> >>        return promise.then(bind);
> >>     
> >>     }
> >>     $.get('/get') '>>=' x => $.post('/save', x + 1)
> >> 
> >> ```
> >> 
> >> Functors
> >> 
> >> ```js
> >> 
> >>     function '.' (inner, outer) {
> >>     
> >>        return function(value: a) : c {
> >>        
> >>           return outer(inner(value))
> >>        
> >>        }
> >>     
> >>     }
> >>     
> >>     function f(x) { }
> >>     function g(y) { }
> >>     (f '.' g)(x); // z
> >> 
> >> ```
> >> 
> >> 
> >> 
> >> Thomas Grainger
> >> 
> >> _______________________________________________
> >> es-discuss mailing list
> >> es-discuss at mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> > 
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180203/d95cb87e/attachment-0001.sig>