I personally do love operator overloading - I am used to it from Lua and Python and I think it can be quite nice.
Likewise I've used it in Haskell/PureScript, Swift, and Scala (also Python and C++ but they don't allow new operators) and infix functions in LiveScript. I enjoy them but question their value proposition. Any discussion should be accompanied by an analysis of previous implementations and their pros and cons relative to the web.
it can be quite fun to make use of operator overloading for a much cleaner description - somewhat like a domain-specific language (DSL) within JS.
This does seem like the primary use case for operators. It's also the primary detractor. Languages like Haskell and Lisp having minimal surface syntax lend themselves to DSLs, while others begin to look obfuscated. Having to name things like "chain" or "then" instead of ">>=" (bind) inherently improves approachability.
Aside from that, we're back into arguments about the clarity benefits of
Ever tried explaining to beginners what the result of [] + {} is, while keeping a straight face?
Each implementation I've used depended on dynamic dispatch based on types. It could be accomplished by making them instance methods like in Scala (and the linked strawman), but overloading builtins seems inadvisable.
With a proper auto-completing editor, this really isn't that difficult.
Agreed OOP is easier to tool than FP in general. Infix operators would have a slight advantage if they were implemented as instance methods. That approach has disadvantages as well.
Plus, there's Sweet.js if you really want it.
Sweet.js currently breaks other tools twitter.com/BrendanEich/status/677685197333204994 like Flow or WebStorm. Otherwise phenomenal but even more difficult to grok (while proportionally more powerful) than operator functions. Until macros are a popular construct (like CoffeeScript was) I don't see the tooling situation improving.
let result = matrix1.multiply(matrix2) works for graphics, but var result = matrix1 * matrix2 could be nice.
In my experience this is the rarest use case for operator functions. In this example matrix multiplication is quite "close to the metal." I'd expect a higher level graphics DSL instead. Overriding existing operators with nuanced meaning is counterproductive and well documented in C++ and Ruby.
I do see value in custom operators. I do not see it as urgent. I do see overloading as detrimental especially in a dynamic system whose polymorphism is limited to prototype lookup.
> overloading was already a for-sure planned feature of ES7, just not fleshed out in a spec.
Is this the proposal <http://wiki.ecmascript.org/doku.php?id=strawman:operator_overloading_with_double_dispatch> you're referring to?
> I personally do love operator overloading - I am used to it from Lua and Python and I think it can be quite nice.
Likewise I've used it in Haskell/PureScript, Swift, and Scala (also Python and C++ but they don't allow new operators) and infix functions in LiveScript. I enjoy them but question their value proposition. Any discussion should be accompanied by an analysis of previous implementations and their pros and cons relative to the web.
> it can be quite fun to make use of operator overloading for a much cleaner description - somewhat like a domain-specific language (DSL) within JS.
This does seem like the primary use case for operators. It's also the primary detractor. Languages like Haskell and Lisp having minimal surface syntax lend themselves to DSLs, while others begin to look obfuscated. Having to name things like "chain" or "then" instead of ">>=" (bind) inherently improves approachability.
> Aside from that, we're back into arguments about the clarity benefits of
>
> * paren-free function invocation
> * non-member, postfix function call syntax, aka `::`
Agreed these issues are postulates of operator functions as seen in the pipeline proposal <https://github.com/mindeavor/es-pipeline-operator/issues/2#issuecomment-164908395>.
> Ever tried explaining to beginners what the result of `[] + {}` is, while keeping a straight face?
Each implementation I've used depended on dynamic dispatch based on types. It could be accomplished by making them instance methods like in Scala (and the linked strawman), but overloading builtins seems inadvisable.
> With a proper auto-completing editor, this really isn't that difficult.
Agreed OOP is easier to tool than FP in general. Infix operators would have a slight advantage if they were implemented as instance methods. That approach has disadvantages as well.
> Plus, there's Sweet.js if you really want it.
Sweet.js currently breaks other tools <https://twitter.com/BrendanEich/status/677685197333204994> like Flow or WebStorm. Otherwise phenomenal but even more difficult to grok (while proportionally more powerful) than operator functions. Until macros are a popular construct (like CoffeeScript was) I don't see the tooling situation improving.
> `let result = matrix1.multiply(matrix2)` works for graphics, but `var result = matrix1 * matrix2` could be nice.
In my experience this is the rarest use case for operator functions. In this example matrix multiplication is quite "close to the metal." I'd expect a higher level graphics DSL instead. Overriding existing operators with nuanced meaning is counterproductive and well documented in C++ and Ruby.
I do see value in custom operators. I do not see it as urgent. I do see overloading as detrimental especially in a dynamic system whose polymorphism is limited to prototype lookup.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151229/c892f050/attachment-0001.html>
Is this the proposal strawman:operator_overloading_with_double_dispatch you're referring to?
Likewise I've used it in Haskell/PureScript, Swift, and Scala (also Python and C++ but they don't allow new operators) and infix functions in LiveScript. I enjoy them but question their value proposition. Any discussion should be accompanied by an analysis of previous implementations and their pros and cons relative to the web.
This does seem like the primary use case for operators. It's also the primary detractor. Languages like Haskell and Lisp having minimal surface syntax lend themselves to DSLs, while others begin to look obfuscated. Having to name things like "chain" or "then" instead of ">>=" (bind) inherently improves approachability.
Agreed these issues are postulates of operator functions as seen in the pipeline proposal mindeavor/es-pipeline-operator#2.
Each implementation I've used depended on dynamic dispatch based on types. It could be accomplished by making them instance methods like in Scala (and the linked strawman), but overloading builtins seems inadvisable.
Agreed OOP is easier to tool than FP in general. Infix operators would have a slight advantage if they were implemented as instance methods. That approach has disadvantages as well.
Sweet.js currently breaks other tools twitter.com/BrendanEich/status/677685197333204994 like Flow or WebStorm. Otherwise phenomenal but even more difficult to grok (while proportionally more powerful) than operator functions. Until macros are a popular construct (like CoffeeScript was) I don't see the tooling situation improving.
In my experience this is the rarest use case for operator functions. In this example matrix multiplication is quite "close to the metal." I'd expect a higher level graphics DSL instead. Overriding existing operators with nuanced meaning is counterproductive and well documented in C++ and Ruby.
I do see value in custom operators. I do not see it as urgent. I do see overloading as detrimental especially in a dynamic system whose polymorphism is limited to prototype lookup.
> overloading was already a for-sure planned feature of ES7, just not fleshed out in a spec. Is this the proposal <http://wiki.ecmascript.org/doku.php?id=strawman:operator_overloading_with_double_dispatch> you're referring to? > I personally do love operator overloading - I am used to it from Lua and Python and I think it can be quite nice. Likewise I've used it in Haskell/PureScript, Swift, and Scala (also Python and C++ but they don't allow new operators) and infix functions in LiveScript. I enjoy them but question their value proposition. Any discussion should be accompanied by an analysis of previous implementations and their pros and cons relative to the web. > it can be quite fun to make use of operator overloading for a much cleaner description - somewhat like a domain-specific language (DSL) within JS. This does seem like the primary use case for operators. It's also the primary detractor. Languages like Haskell and Lisp having minimal surface syntax lend themselves to DSLs, while others begin to look obfuscated. Having to name things like "chain" or "then" instead of ">>=" (bind) inherently improves approachability. > Aside from that, we're back into arguments about the clarity benefits of > > * paren-free function invocation > * non-member, postfix function call syntax, aka `::` Agreed these issues are postulates of operator functions as seen in the pipeline proposal <https://github.com/mindeavor/es-pipeline-operator/issues/2#issuecomment-164908395>. > Ever tried explaining to beginners what the result of `[] + {}` is, while keeping a straight face? Each implementation I've used depended on dynamic dispatch based on types. It could be accomplished by making them instance methods like in Scala (and the linked strawman), but overloading builtins seems inadvisable. > With a proper auto-completing editor, this really isn't that difficult. Agreed OOP is easier to tool than FP in general. Infix operators would have a slight advantage if they were implemented as instance methods. That approach has disadvantages as well. > Plus, there's Sweet.js if you really want it. Sweet.js currently breaks other tools <https://twitter.com/BrendanEich/status/677685197333204994> like Flow or WebStorm. Otherwise phenomenal but even more difficult to grok (while proportionally more powerful) than operator functions. Until macros are a popular construct (like CoffeeScript was) I don't see the tooling situation improving. > `let result = matrix1.multiply(matrix2)` works for graphics, but `var result = matrix1 * matrix2` could be nice. In my experience this is the rarest use case for operator functions. In this example matrix multiplication is quite "close to the metal." I'd expect a higher level graphics DSL instead. Overriding existing operators with nuanced meaning is counterproductive and well documented in C++ and Ruby. I do see value in custom operators. I do not see it as urgent. I do see overloading as detrimental especially in a dynamic system whose polymorphism is limited to prototype lookup. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151229/c892f050/attachment-0001.html>