Re: Trailing comma for function arguments and call parameters
On Tue, Jul 8, 2014 at 1:40 AM, Dmitry Soshnikov dmitry.soshni...@gmail.com wrote: On Sun, Jul 6, 2014 at 10:36 PM, Isiah Meadows impinb...@gmail.com wrote: My responses are inline. From: Alex Kocharin a...@kocharin.ru To: Oliver Hunt oli...@apple.com, Dmitry Soshnikov dmitry.soshni...@gmail.com Cc: es-discuss es-discuss@mozilla.org Date: Sun, 06 Jul 2014 12:07:09 +0400 Subject: Re: Trailing comma for function arguments and call parameters In fact, how about the same syntax for arrays and function calls? With trailing commas and elisions? So foo(1,,3,,) would be an alias for foo(1,undefined,3,undefined) ? 06.07.2014, 11:57, Alex Kocharin a...@kocharin.ru: Unless you use leading comma style, trailing commas are very good to have for anything that has variable amount of items/keys/arguments. This is a classic example I use to show why JSON is a bad idea: https://github.com/npm/npm/commit/20439b21e103f6c1e8dcf2938ebaffce394bf23d#diff-6 I believe the same thing applies for javascript functions. If it was a bug in javascript, I wish for more such bugs really... 04.07.2014, 20:33, Oliver Hunt oli...@apple.com: On Jul 3, 2014, at 3:52 PM, Dmitry Soshnikov dmitry.soshni...@gmail.com wrote: Hi, Will it makes sense to standardize a trailing comma for function arguments, and call parameters? 2. Function statements usually don't have such long lists of arguments that such a thing would truly become useful. That is rare even in C, where you may have as many as 6 or 7 arguments for one function. Yes, it's true, however, my use-case was based on 80-cols rule we use in our code-base. And with type annotations (especially type annotations with generics, when you have types like `Mapstring, IParamDefinition $params`, etc) it can quickly become more than 80 cols, and our style-guide is to use each parameter on its own line, with a trailing comma for convenience of future adding that will preserve git blame logs if one doesn't need always append the comma on previous line, in case when adding a new parameter Another example can be found by looking at pretty much any Angular-based codebase, due to the dependency injection. +1 from me for this. Anything that makes changesets easier to contain makes me happier. I also think it'd be a nice for syntax consistency to support this. Cheers, Jussi Dmitry ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Trailing comma for function arguments and call parameters
On Fri, Jul 4, 2014 at 12:52 AM, Dmitry Soshnikov dmitry.soshni...@gmail.com wrote: Will it makes sense to standardize a trailing comma for function arguments, and call parameters? Fwiw, it also makes sense in AMD, where the set of dependencies can grow and the desire to put every module on its own line becomes desirable. I tend to do it for the array since you can be consistent with the leading/trailing comma there, but not so much for the func args. Allowing an empty comma after the param list could fix that. Also allowing one before for the comma-first people would be nice. But again, I already think that for the language itself, it won't be super useful just yet, since backward-incompatible syntax won't allow using it anyways for a long amount of time This argument doesn't hold for server side approaches like node, or build-step approaches like you use yourself. Also, if you apply this argument to any new syntax the language never changes, for better or worse ;) Anyways, +1 from me. I'm tired of irrelevant diff lines... - peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Efficient 64 bit arithmetic
Hi all, Regarding 64 bit arithmetic, there is a simpler solution compared to what was proposed in [1]. It is already possible to get the low 32 bit part of the 64 bit operations for addition, subtraction and multiplication. So it is enough to add a few more functions to get the high 32 bit part of 64 bit additions, subtractions and multiplications. Hence I propose to add the following functions: Math.iaddh(lo0, hi0, lo1, hi1) : return the high 32 bit part of the 64 bit addition of (hi0, lo0) and (hi1, lo1). Math.isubh(lo0, hi0, lo1, hi1) : return the high 32 bit part of the 64 bit subtraction of (hi0, lo0) and (hi1, lo1). Math.imulh(a, b) : return the high 32 bit part of the signed 64 bit product of the 32 bit numbers a and b. Math.imuluh(a, b) : return the high 32 bit part of the unsigned 64 bit product of the 32 bit numbers a and b. All these functions convert their argument to 32 bit integers. They return a signed 32 bit integer. With these functions, the 64 bit operations are easy to implement : - (hi_res, lo_res) = (hi0, lo0) + (hi1, lo1) (64 bit addition): lo_res = (lo0 + lo1) | 0; hi_res = Math.iaddh(lo0, hi0, lo1, hi1); - (hi_res, lo_res) = (hi0, lo0) - (hi1, lo1) (64 bit subtraction): lo_res = (lo0 - lo1) | 0; hi_res = Math.isubh(lo0, hi0, lo1, hi1); - (hi_res, lo_res) = a * b (signed 64 bit product of 32 bit integers): lo_res = Math.imul(a, b); hi_res = Math.imulh(a, b); - (hi_res, lo_res) = a * b (unsigned 64 bit product of 32 bit integers): lo_res = Math.imul(a, b); hi_res = Math.imuluh(a, b); - (hi_res, lo_res) = (hi0, lo0) * (hi1, lo1) (signed 64 bit product of 64 bit integers): lo_res = Math.imul(lo0, lo1); hi_res = (Math.imulh(lo0, lo1) + Math.imul(lo0, hi1)) | 0; hi_res = (hi_res + Math.imul(lo1, hi0)) | 0; - (hi_res, lo_res) = (hi0, lo0) * (hi1, lo1) (unsigned 64 bit product of 64 bit integers): lo_res = Math.imul(lo0, lo1); hi_res = (Math.imuluh(lo0, lo1) + Math.imul(lo0, hi1)) | 0; hi_res = (hi_res + Math.imul(lo1, hi0)) | 0; It is easy for the compiler to optimize the code because only 32 bit integers are used and because the functions have no side effect. Even if the compiler does not remove the duplicate operation for the low 32 bit parts, the overhead is very small on a 32 bit CPU (1 more instruction than the optimal code). Fabrice. [1] https://www.mail-archive.com/es-discuss%40mozilla.org/msg27237.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Efficient 64 bit arithmetic
I like this a lot. It looks like it will have a fairly mellow performance cliff in cases where VM optimizations fail for whatever reason, since even in a lower-tier compiler incapable of sophisticated optimizations all you really have to do is make sure that these new math function calls bottom out in something efficient. This would be even better if there was a story for div and mod. Is there one? -Filip On Jul 8, 2014, at 7:59 AM, Fabrice Bellard fabr...@bellard.org wrote: Hi all, Regarding 64 bit arithmetic, there is a simpler solution compared to what was proposed in [1]. It is already possible to get the low 32 bit part of the 64 bit operations for addition, subtraction and multiplication. So it is enough to add a few more functions to get the high 32 bit part of 64 bit additions, subtractions and multiplications. Hence I propose to add the following functions: Math.iaddh(lo0, hi0, lo1, hi1) : return the high 32 bit part of the 64 bit addition of (hi0, lo0) and (hi1, lo1). Math.isubh(lo0, hi0, lo1, hi1) : return the high 32 bit part of the 64 bit subtraction of (hi0, lo0) and (hi1, lo1). Math.imulh(a, b) : return the high 32 bit part of the signed 64 bit product of the 32 bit numbers a and b. Math.imuluh(a, b) : return the high 32 bit part of the unsigned 64 bit product of the 32 bit numbers a and b. All these functions convert their argument to 32 bit integers. They return a signed 32 bit integer. With these functions, the 64 bit operations are easy to implement : - (hi_res, lo_res) = (hi0, lo0) + (hi1, lo1) (64 bit addition): lo_res = (lo0 + lo1) | 0; hi_res = Math.iaddh(lo0, hi0, lo1, hi1); - (hi_res, lo_res) = (hi0, lo0) - (hi1, lo1) (64 bit subtraction): lo_res = (lo0 - lo1) | 0; hi_res = Math.isubh(lo0, hi0, lo1, hi1); - (hi_res, lo_res) = a * b (signed 64 bit product of 32 bit integers): lo_res = Math.imul(a, b); hi_res = Math.imulh(a, b); - (hi_res, lo_res) = a * b (unsigned 64 bit product of 32 bit integers): lo_res = Math.imul(a, b); hi_res = Math.imuluh(a, b); - (hi_res, lo_res) = (hi0, lo0) * (hi1, lo1) (signed 64 bit product of 64 bit integers): lo_res = Math.imul(lo0, lo1); hi_res = (Math.imulh(lo0, lo1) + Math.imul(lo0, hi1)) | 0; hi_res = (hi_res + Math.imul(lo1, hi0)) | 0; - (hi_res, lo_res) = (hi0, lo0) * (hi1, lo1) (unsigned 64 bit product of 64 bit integers): lo_res = Math.imul(lo0, lo1); hi_res = (Math.imuluh(lo0, lo1) + Math.imul(lo0, hi1)) | 0; hi_res = (hi_res + Math.imul(lo1, hi0)) | 0; It is easy for the compiler to optimize the code because only 32 bit integers are used and because the functions have no side effect. Even if the compiler does not remove the duplicate operation for the low 32 bit parts, the overhead is very small on a 32 bit CPU (1 more instruction than the optimal code). Fabrice. [1] https://www.mail-archive.com/es-discuss%40mozilla.org/msg27237.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Efficient 64 bit arithmetic
Latest news on div AFAIK: https://mail.mozilla.org/pipermail/es-discuss/2013-July/thread.html#32221 On Tue, Jul 8, 2014 at 10:45 AM, Filip Pizlo fpi...@apple.com wrote: I like this a lot. It looks like it will have a fairly mellow performance cliff in cases where VM optimizations fail for whatever reason, since even in a lower-tier compiler incapable of sophisticated optimizations all you really have to do is make sure that these new math function calls bottom out in something efficient. This would be even better if there was a story for div and mod. Is there one? -Filip On Jul 8, 2014, at 7:59 AM, Fabrice Bellard fabr...@bellard.org wrote: Hi all, Regarding 64 bit arithmetic, there is a simpler solution compared to what was proposed in [1]. It is already possible to get the low 32 bit part of the 64 bit operations for addition, subtraction and multiplication. So it is enough to add a few more functions to get the high 32 bit part of 64 bit additions, subtractions and multiplications. Hence I propose to add the following functions: Math.iaddh(lo0, hi0, lo1, hi1) : return the high 32 bit part of the 64 bit addition of (hi0, lo0) and (hi1, lo1). Math.isubh(lo0, hi0, lo1, hi1) : return the high 32 bit part of the 64 bit subtraction of (hi0, lo0) and (hi1, lo1). Math.imulh(a, b) : return the high 32 bit part of the signed 64 bit product of the 32 bit numbers a and b. Math.imuluh(a, b) : return the high 32 bit part of the unsigned 64 bit product of the 32 bit numbers a and b. All these functions convert their argument to 32 bit integers. They return a signed 32 bit integer. With these functions, the 64 bit operations are easy to implement : - (hi_res, lo_res) = (hi0, lo0) + (hi1, lo1) (64 bit addition): lo_res = (lo0 + lo1) | 0; hi_res = Math.iaddh(lo0, hi0, lo1, hi1); - (hi_res, lo_res) = (hi0, lo0) - (hi1, lo1) (64 bit subtraction): lo_res = (lo0 - lo1) | 0; hi_res = Math.isubh(lo0, hi0, lo1, hi1); - (hi_res, lo_res) = a * b (signed 64 bit product of 32 bit integers): lo_res = Math.imul(a, b); hi_res = Math.imulh(a, b); - (hi_res, lo_res) = a * b (unsigned 64 bit product of 32 bit integers): lo_res = Math.imul(a, b); hi_res = Math.imuluh(a, b); - (hi_res, lo_res) = (hi0, lo0) * (hi1, lo1) (signed 64 bit product of 64 bit integers): lo_res = Math.imul(lo0, lo1); hi_res = (Math.imulh(lo0, lo1) + Math.imul(lo0, hi1)) | 0; hi_res = (hi_res + Math.imul(lo1, hi0)) | 0; - (hi_res, lo_res) = (hi0, lo0) * (hi1, lo1) (unsigned 64 bit product of 64 bit integers): lo_res = Math.imul(lo0, lo1); hi_res = (Math.imuluh(lo0, lo1) + Math.imul(lo0, hi1)) | 0; hi_res = (hi_res + Math.imul(lo1, hi0)) | 0; It is easy for the compiler to optimize the code because only 32 bit integers are used and because the functions have no side effect. Even if the compiler does not remove the duplicate operation for the low 32 bit parts, the overhead is very small on a 32 bit CPU (1 more instruction than the optimal code). Fabrice. [1] https://www.mail-archive.com/es-discuss%40mozilla.org/msg27237.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Efficient 64 bit arithmetic
That’s unrelated, since that discussion deals with integer division for the domain of integers that is representable using ES numbers (i.e. IEEE doubles). This discussion, and my question about division, is in regards to 64-bit arithmetic. 64-bit integers do not fit into ES numbers, and so you need the lo/hi pairs like what Fabrice proposes (or some kind of value objects, which would be a different beast). For the lo/hi pair approach, we logically want a division like: (lo, hi) = Math.idiv64(lo0, hi0, lo1, hi1) I am wondering if Fabrice has ideas about how to represent this. -Filip On Jul 8, 2014, at 9:19 AM, Michael Haufe t...@thenewobjective.com wrote: Latest news on div AFAIK: https://mail.mozilla.org/pipermail/es-discuss/2013-July/thread.html#32221 On Tue, Jul 8, 2014 at 10:45 AM, Filip Pizlo fpi...@apple.com wrote: I like this a lot. It looks like it will have a fairly mellow performance cliff in cases where VM optimizations fail for whatever reason, since even in a lower-tier compiler incapable of sophisticated optimizations all you really have to do is make sure that these new math function calls bottom out in something efficient. This would be even better if there was a story for div and mod. Is there one? -Filip On Jul 8, 2014, at 7:59 AM, Fabrice Bellard fabr...@bellard.org wrote: Hi all, Regarding 64 bit arithmetic, there is a simpler solution compared to what was proposed in [1]. It is already possible to get the low 32 bit part of the 64 bit operations for addition, subtraction and multiplication. So it is enough to add a few more functions to get the high 32 bit part of 64 bit additions, subtractions and multiplications. Hence I propose to add the following functions: Math.iaddh(lo0, hi0, lo1, hi1) : return the high 32 bit part of the 64 bit addition of (hi0, lo0) and (hi1, lo1). Math.isubh(lo0, hi0, lo1, hi1) : return the high 32 bit part of the 64 bit subtraction of (hi0, lo0) and (hi1, lo1). Math.imulh(a, b) : return the high 32 bit part of the signed 64 bit product of the 32 bit numbers a and b. Math.imuluh(a, b) : return the high 32 bit part of the unsigned 64 bit product of the 32 bit numbers a and b. All these functions convert their argument to 32 bit integers. They return a signed 32 bit integer. With these functions, the 64 bit operations are easy to implement : - (hi_res, lo_res) = (hi0, lo0) + (hi1, lo1) (64 bit addition): lo_res = (lo0 + lo1) | 0; hi_res = Math.iaddh(lo0, hi0, lo1, hi1); - (hi_res, lo_res) = (hi0, lo0) - (hi1, lo1) (64 bit subtraction): lo_res = (lo0 - lo1) | 0; hi_res = Math.isubh(lo0, hi0, lo1, hi1); - (hi_res, lo_res) = a * b (signed 64 bit product of 32 bit integers): lo_res = Math.imul(a, b); hi_res = Math.imulh(a, b); - (hi_res, lo_res) = a * b (unsigned 64 bit product of 32 bit integers): lo_res = Math.imul(a, b); hi_res = Math.imuluh(a, b); - (hi_res, lo_res) = (hi0, lo0) * (hi1, lo1) (signed 64 bit product of 64 bit integers): lo_res = Math.imul(lo0, lo1); hi_res = (Math.imulh(lo0, lo1) + Math.imul(lo0, hi1)) | 0; hi_res = (hi_res + Math.imul(lo1, hi0)) | 0; - (hi_res, lo_res) = (hi0, lo0) * (hi1, lo1) (unsigned 64 bit product of 64 bit integers): lo_res = Math.imul(lo0, lo1); hi_res = (Math.imuluh(lo0, lo1) + Math.imul(lo0, hi1)) | 0; hi_res = (hi_res + Math.imul(lo1, hi0)) | 0; It is easy for the compiler to optimize the code because only 32 bit integers are used and because the functions have no side effect. Even if the compiler does not remove the duplicate operation for the low 32 bit parts, the overhead is very small on a 32 bit CPU (1 more instruction than the optimal code). Fabrice. [1] https://www.mail-archive.com/es-discuss%40mozilla.org/msg27237.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
