Operator overloading proposal

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Operator overloading proposal

Keith Cirkel-2
Hello all!

While I am aware that previous proposals for operator overloading exist, I thought I'd attempt to write one which I consider to be simpler and more extensible - utilising Symbols.

https://github.com/keithamus/ecmascript-operator-overloading-proposal

It'd be great to get some feedback to this, and discuss the opportunity of getting a champion to work with me on this!
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Operator overloading proposal

kdex
Your README.md reads:

> Where an operator is used with two operands of the *same type*, […]

How would a binary operator work with operands of *different* type (by which I
assume we mean its constructor)?

On Friday, July 14, 2017 12:22:25 AM CEST Keith Cirkel wrote:

> Hello all!
>
> While I am aware that previous proposals for operator overloading exist, I
> thought I'd attempt to write one which I consider to be simpler and more
> extensible - utilising Symbols.
>
> https://github.com/keithamus/ecmascript-operator-overloading-proposal
>
> It'd be great to get some feedback to this, and discuss the opportunity of
> getting a champion to work with me on this!
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Operator overloading proposal

Oriol _
In reply to this post by Keith Cirkel-2

Some problems I noticed at first glance:

> Prefix/Postfix Unary Increment: `++`

But postfix and prefix increments are supposed to return different values. How does this work if they are the same symbol?

> Loose inequality Comparison: `!=`

You didn't include it for consistency. Shouldn't `!` also be excluded, then?

> Future: Extending of operators

I don't think this can work if you don't define a way to determine the operands.

--Oriol

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Operator overloading proposal

kai zhu
-1

javascript operator-overloading is a solution in search of a problem.  there is virtually no real-world use-case where this feature would would not cause surprises and code-bloat (from bloated and unmaintainable polymorphic classes dealing with all the edge cases).

just imagine all the “fun” you would have debugging everyone else’s projects with operators your not completely confident will behave as expected.

On Jul 14, 2017, at 7:59 AM, Oriol _ <[hidden email]> wrote:

Some problems I noticed at first glance:

> Prefix/Postfix Unary Increment: `++`

But postfix and prefix increments are supposed to return different values. How does this work if they are the same symbol?

> Loose inequality Comparison: `!=`

You didn't include it for consistency. Shouldn't `!` also be excluded, then?

> Future: Extending of operators

I don't think this can work if you don't define a way to determine the operands.

--Oriol
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: operator overloading proposal

Boris Cherny
In reply to this post by Keith Cirkel-2
> javascript operator-overloading is a solution in search of a problem.

Why is JS different than languages that treat operators as methods, and make heavy use of overloading (Scala, Haskell, ...)? There seem to be lots of good use cases, same as in other languages.

> On Jul 13, 2017, at 5:07 PM, [hidden email] wrote:
>
> Send es-discuss mailing list submissions to
>    [hidden email]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>    https://mail.mozilla.org/listinfo/es-discuss
> or, via email, send a message with subject or body 'help' to
>    [hidden email]
>
> You can reach the person managing the list at
>    [hidden email]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of es-discuss digest..."
> Today's Topics:
>
>   1. Operator overloading proposal (Keith Cirkel)
>   2. Re: Operator overloading proposal (kdex)
>   3. Re: Operator overloading proposal (Oriol _)
>   4. Re: Operator overloading proposal (kai zhu)
> <mime-attachment>
> <mime-attachment>
> <mime-attachment>
> <mime-attachment>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: Operator overloading proposal

Bruno Jouhier
In reply to this post by Keith Cirkel-2
> javascript operator-overloading is a solution in search of a problem. 

No. It is a solution to a problem I have today: arithmetic on decimal values.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Operator overloading proposal

kai zhu
> No. It is a solution to a problem I have today: arithmetic on decimal values.

would you enjoy debugging someone else’s production-code with overloaded decimal operators? or would you prefer them having the courtesy to use method-calls, thus saving the headache of having to inspect every arithmetic expression?

> On Jul 14, 2017, at 4:30 PM, Bruno Jouhier <[hidden email]> wrote:
>
> > javascript operator-overloading is a solution in search of a problem.
>
> No. It is a solution to a problem I have today: arithmetic on decimal values.
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: operator overloading proposal

Isiah Meadows-2
In reply to this post by Boris Cherny
Two primary concerns:

1. JS uses proxies for a few similar hooks (like `foo["prop"]` and `foo()`) now. Python uses `__getattr__` and `__call__` for those, but JS doesn't use magic methods for those.

2. Performance is going to be much harder to ensure, especially if you can mutate the operator methods them after creation. Scala, Haskell, C++, and the like can get away with operator functions/methods without a perf cliff, since they assume the operator to never change. You don't have that luxury with JS symbols - they *can* change. This is no different than in Python, and it's part of why PyPy is much slower than JS. LuaJIT only handles them well because a) Lua is very simple to begin with, and b) it does highly sophisticated analysis not seen in any other runtime, engineered by one of the top JIT and assembly experts in the field. (See Luafun for an example of its abilities, including its source code.)

On Thu, Jul 13, 2017, 23:56 Boris Cherny <[hidden email]> wrote:
> javascript operator-overloading is a solution in search of a problem.

Why is JS different than languages that treat operators as methods, and make heavy use of overloading (Scala, Haskell, ...)? There seem to be lots of good use cases, same as in other languages.

> On Jul 13, 2017, at 5:07 PM, [hidden email] wrote:
>
> Send es-discuss mailing list submissions to
>    [hidden email]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>    https://mail.mozilla.org/listinfo/es-discuss
> or, via email, send a message with subject or body 'help' to
>    [hidden email]
>
> You can reach the person managing the list at
>    [hidden email]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of es-discuss digest..."
> Today's Topics:
>
>   1. Operator overloading proposal (Keith Cirkel)
>   2. Re: Operator overloading proposal (kdex)
>   3. Re: Operator overloading proposal (Oriol _)
>   4. Re: Operator overloading proposal (kai zhu)
> <mime-attachment>
> <mime-attachment>
> <mime-attachment>
> <mime-attachment>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Operator overloading proposal

Isiah Meadows-2
In reply to this post by kai zhu
It would actually be of substantial benefit to readability if you *could* overload operators for numeric, vector, and matrix-like types. In particular, I'd strongly prefer if SIMD types, if added, *did* use overloaded operators similarly to the BigInt proposal - it's honestly ridiculous why people use SIMD intrinsics for things that equate to vector addition (in the math sense).

In particular, here's a couple examples of what I mean from a math standpoint:

Vector (3D point) addition:

<a, b, c> + <x, y, z> = <a+x, b+y, c+z>

Matrix multiplication (2D):

[a, b]    [x, y]
[c, d] × [z, w] =

[ax+bz, ax+bw]
[cx+dz, cx+dw]

Complex number division:

(a + bi) ÷ (c + di) =

(ac+bd) + i(bc - ad)
--------------------------------
           c²+d²

Set symmetric difference (i.e. exclusive or):

{1, 2, 3} ⊕ {1, 2, 4} = {3, 4}

I'd strongly prefer an operator variant over any method version, because it matches the math notation much better. You shouldn't actually need to learn some naming idiom just to add two things.

On Fri, Jul 14, 2017, 04:49 kai zhu <[hidden email]> wrote:
> No. It is a solution to a problem I have today: arithmetic on decimal values.

would you enjoy debugging someone else’s production-code with overloaded decimal operators? or would you prefer them having the courtesy to use method-calls, thus saving the headache of having to inspect every arithmetic expression?

> On Jul 14, 2017, at 4:30 PM, Bruno Jouhier <[hidden email]> wrote:
>
> > javascript operator-overloading is a solution in search of a problem.
>
> No. It is a solution to a problem I have today: arithmetic on decimal values.
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Operator overloading proposal

kai zhu
overloaded simd-operators is again a solution in search of a problem. complex-arithmetic and matrix-operators has no significant application in the web-industry.

also, my experience with numeric javascript apps has been that generic matrix operations never quite do what i want, and the scope of handling NaN / Infinity / transpose edge-cases can be overwhelming.  its more robust, efficient, and maintainable to handle these edge-cases with custom for-loop code than a mashup of matrix operations.

On Jul 14, 2017, at 6:02 PM, Isiah Meadows <[hidden email]> wrote:

It would actually be of substantial benefit to readability if you *could* overload operators for numeric, vector, and matrix-like types. In particular, I'd strongly prefer if SIMD types, if added, *did* use overloaded operators similarly to the BigInt proposal - it's honestly ridiculous why people use SIMD intrinsics for things that equate to vector addition (in the math sense).

In particular, here's a couple examples of what I mean from a math standpoint:

Vector (3D point) addition:

<a, b, c> + <x, y, z> = <a+x, b+y, c+z>

Matrix multiplication (2D):

[a, b]    [x, y]
[c, d] × [z, w] =

[ax+bz, ax+bw]
[cx+dz, cx+dw]

Complex number division:

(a + bi) ÷ (c + di) =

(ac+bd) + i(bc - ad)
--------------------------------
           c²+d²

Set symmetric difference (i.e. exclusive or):

{1, 2, 3} ⊕ {1, 2, 4} = {3, 4}

I'd strongly prefer an operator variant over any method version, because it matches the math notation much better. You shouldn't actually need to learn some naming idiom just to add two things.

On Fri, Jul 14, 2017, 04:49 kai zhu <[hidden email]> wrote:
> No. It is a solution to a problem I have today: arithmetic on decimal values.

would you enjoy debugging someone else’s production-code with overloaded decimal operators? or would you prefer them having the courtesy to use method-calls, thus saving the headache of having to inspect every arithmetic expression?

> On Jul 14, 2017, at 4:30 PM, Bruno Jouhier <[hidden email]> wrote:
>
> > javascript operator-overloading is a solution in search of a problem.
>
> No. It is a solution to a problem I have today: arithmetic on decimal values.
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Operator overloading proposal

Bruno Jouhier
In reply to this post by kai zhu
> > No. It is a solution to a problem I have today: arithmetic on decimal values.
> would you enjoy debugging someone else’s production-code with overloaded decimal operators? or would you prefer them having the courtesy to use method-calls, thus saving the headache of having to inspect every arithmetic expression?

Well, my context is business apps (accounting). Lots of developers writing lots of rules doing arithmetics on decimal quantities (JS number is not an option). Operators will keep the code concise, readable and familiar.

Code will be TypeScript so there will be typing hints everywhere (tooltips too) and debug-ability should not be an issue.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Operator overloading proposal

Michał Wadas
To be honest, I recommend to abandon all ideas of operator overloading for arbitrary types - that's extremely unlikely to happen. It's heavily affects optimization possibilities, requires extensive type checks. Moreover, there is no interest from browser vendors to implement it. 

However, I expect that in far future we will be able to overload operators if we get structs (having native complex numbers and matrices would be great). 


On 14 Jul 2017 3:04 pm, "Bruno Jouhier" <[hidden email]> wrote:
> > No. It is a solution to a problem I have today: arithmetic on decimal values.
> would you enjoy debugging someone else’s production-code with overloaded decimal operators? or would you prefer them having the courtesy to use method-calls, thus saving the headache of having to inspect every arithmetic expression?

Well, my context is business apps (accounting). Lots of developers writing lots of rules doing arithmetics on decimal quantities (JS number is not an option). Operators will keep the code concise, readable and familiar.

Code will be TypeScript so there will be typing hints everywhere (tooltips too) and debug-ability should not be an issue.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Operator overloading proposal

Bruno Jouhier
You mean this? https://www.slideshare.net/BrendanEich/int64 (slide 12 and following)
This would be cool.

2017-07-14 18:03 GMT+02:00 Michał Wadas <[hidden email]>:
To be honest, I recommend to abandon all ideas of operator overloading for arbitrary types - that's extremely unlikely to happen. It's heavily affects optimization possibilities, requires extensive type checks. Moreover, there is no interest from browser vendors to implement it. 

However, I expect that in far future we will be able to overload operators if we get structs (having native complex numbers and matrices would be great). 


On 14 Jul 2017 3:04 pm, "Bruno Jouhier" <[hidden email]> wrote:
> > No. It is a solution to a problem I have today: arithmetic on decimal values.
> would you enjoy debugging someone else’s production-code with overloaded decimal operators? or would you prefer them having the courtesy to use method-calls, thus saving the headache of having to inspect every arithmetic expression?

Well, my context is business apps (accounting). Lots of developers writing lots of rules doing arithmetics on decimal quantities (JS number is not an option). Operators will keep the code concise, readable and familiar.

Code will be TypeScript so there will be typing hints everywhere (tooltips too) and debug-ability should not be an issue.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Loading...