Re: Array.prototype.joinWith(iterable)
For that, I'd rather see an `interleave` that just rotates through all
its arguments. It'd be basically sugar for `.zip().flat()`, but an
implementation could optimize the heck out of it. (In particular, they
could iterate through them one-by-one and only allocate once, not in
the hot loop, so it'd be fast.)
I at one point had it in my list of wishlist proposals, but it somehow
disappeared. I've since recreated it:
https://github.com/isiahmeadows/es-stdlib-proposals/blob/master/proposals/array/interleave.md
-
Isiah Meadows
cont...@isiahmeadows.com
www.isiahmeadows.com
On Thu, Aug 15, 2019 at 1:12 PM Andrea Giammarchi
wrote:
>
> That;s not useful for template literals tags though
>
> _.zip(['a', 'b', 'c'], [1, 2]);
> [["a", 1], ["b", 2], ["c", undefined]]
>
> it basically does nothing I've proposed ... any other name suggestion?
>
> On Thu, Aug 15, 2019 at 3:40 PM Michał Wadas wrote:
>>
>> https://lodash.com/docs/#zip
>> https://docs.python.org/3/library/functions.html#zip
>>
>> On Thu, 15 Aug 2019, 15:34 Andrea Giammarchi,
>> wrote:
>>>
>>> the suggested name is just ... suggested, I don't have strong opinion on
>>> it, it just `join` values through other values
>>> what's `Array.zip` ? I've no idea
>>>
>>>
>>> On Thu, Aug 15, 2019 at 12:53 PM Michał Wadas wrote:
I would rather see Array.zip, it covers this use case.
On Thu, 15 Aug 2019, 10:50 Andrea Giammarchi,
wrote:
>
>
> I wonder if there's any interest in adding another handy Array method as
> joinWith could be:
>
> ```js
> // proposal example
> Array.prototype.joinWith = function (values) {
> const {length} = this;
> if (length < 2)
> return this.join('');
> const out = [this[0]];
> const len = values.length;
> for (let i = 1; i < length; i++) {
> console.log(i, len);
> out.push(values[(i - 1) % len], this[i]);
> }
> return out.join('');
> };
> ```
>
> The goal is to simplify joining array entries through not the same value,
> example:
>
> ```js
> console.log(['a', 'b', 'c', 'd'].joinWith([1, 2]));
> // a1b2c1d
>
> function tag2str(template, ...values) {
> return template.joinWith(values);
> }
>
> tag2str`a${1}b${2}c`;
> // "a1b2c"
> ```
>
> Throughts?
> ___
> 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: Array.prototype.findIndex(fn, startIndex = 0)
I believe every array iteration method that takes a callback, except for
reduce and reduceRight, take an optional receiver as the last argument (the
`this` value), so they can't be meaningfully/ergonomically extended.
On Thu, Aug 15, 2019 at 3:00 PM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> isn't the second argument already reserved for the context?
>
> ```js
> [1, 2, 3].findIndex(function (i) { return i == this; }, 2);
> // 1
> ```
>
> On Thu, Aug 15, 2019 at 11:51 PM Cyril Auburtin
> wrote:
>
>> It should be possible to add a second optional argument to the `find` and
>> `findIndex` array methods, similarly to `indexOf`
>> ___
>> 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: Array.prototype.findIndex(fn, startIndex = 0)
isn't the second argument already reserved for the context?
```js
[1, 2, 3].findIndex(function (i) { return i == this; }, 2);
// 1
```
On Thu, Aug 15, 2019 at 11:51 PM Cyril Auburtin
wrote:
> It should be possible to add a second optional argument to the `find` and
> `findIndex` array methods, similarly to `indexOf`
> ___
> 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
Array.prototype.findIndex(fn, startIndex = 0)
It should be possible to add a second optional argument to the `find` and `findIndex` array methods, similarly to `indexOf` ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.joinWith(iterable)
There is a whole example that produces a string, like join does, using the
second argument iterable to fill the "junctions" ... which part is not
clear in the test case?
```js
console.log(['a', 'b', 'c', 'd'].joinWith([1, 2]));
// a1b2c1d
function tag2str(template, ...values) {
return template.joinWith(values);
}
tag2str`a${1}b${2}c`;
// "a1b2c"
```
On Thu, Aug 15, 2019 at 7:39 PM Naveen Chawla wrote:
> "weave"? (I've likely missed the purpose of the method)
>
> On Thu, 15 Aug 2019, 18:12 Andrea Giammarchi,
> wrote:
>
>> That;s not useful for template literals tags though
>>
>> _.zip(['a', 'b', 'c'], [1, 2]);
>> [["a", 1], ["b", 2], ["c", undefined]]
>>
>> it basically does nothing I've proposed ... any other name suggestion?
>>
>> On Thu, Aug 15, 2019 at 3:40 PM Michał Wadas
>> wrote:
>>
>>> https://lodash.com/docs/#zip
>>> https://docs.python.org/3/library/functions.html#zip
>>>
>>> On Thu, 15 Aug 2019, 15:34 Andrea Giammarchi, <
>>> andrea.giammar...@gmail.com> wrote:
>>>
1. the suggested name is just ... suggested, I don't have strong
opinion on it, it just `join` values through other values
2. what's `Array.zip` ? I've no idea
On Thu, Aug 15, 2019 at 12:53 PM Michał Wadas
wrote:
> I would rather see Array.zip, it covers this use case.
>
> On Thu, 15 Aug 2019, 10:50 Andrea Giammarchi, <
> andrea.giammar...@gmail.com> wrote:
>
>>
>> I wonder if there's any interest in adding another handy Array method
>> as joinWith could be:
>>
>> ```js
>> // proposal example
>> Array.prototype.joinWith = function (values) {
>> const {length} = this;
>> if (length < 2)
>> return this.join('');
>> const out = [this[0]];
>> const len = values.length;
>> for (let i = 1; i < length; i++) {
>> console.log(i, len);
>> out.push(values[(i - 1) % len], this[i]);
>> }
>> return out.join('');
>> };
>> ```
>>
>> The goal is to simplify joining array entries through not the same
>> value, example:
>>
>> ```js
>> console.log(['a', 'b', 'c', 'd'].joinWith([1, 2]));
>> // a1b2c1d
>>
>> function tag2str(template, ...values) {
>> return template.joinWith(values);
>> }
>>
>> tag2str`a${1}b${2}c`;
>> // "a1b2c"
>> ```
>>
>> Throughts?
>> ___
>> 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: Modulo Operator %%
BTW, I just wrote up a more precise, formalized proposal over here: https://github.com/isiahmeadows/proposal-divisor-dependent-modulo/, and I'd be more than willing to work with a TC39 champion on it. I personally prefer syntax (pretty strongly), but I'm not beholden to it. I do feel the semantics are simple enough it'd be okay to lower it to syntax, and it naturally just glides right in. I find it *very* odd that some languages use a simple operator `%` or relatively short function for remainder keeping the sign of the dividend but relegate the version keeping the sign of the divisor (the more useful and intuitive of them) to a much more verbose function call. Of all Wikipedia lists in https://en.wikipedia.org/wiki/Modulo_operation, here's the four that do this currently - all but one expose an operator for the first: - Fortran: `mod` for dividend-dependent, `modulo` for divisor-dependent - Julia: `%`/`rem` for dividend-dependent, `mod` for divisor-dependent - Java: `%` for dividend-dependent, `Math.floorMod` for divisor-dependent - XBase++: `%` for dividend-dependent, `Mod` for divisor-dependent And it's worth noting most other languages (including some end user-oriented ones) that show a syntactic preference to one or the other expose a simpler one where the sign matches the divisor, a more complicated one where the sign matches the dividend. For a variety of examples: - Ruby: `%`/`modulo` for divisor-dependent, `remainder` for dividend-dependent - SML: `mod` for divisor-dependent, `Int.rem` for dividend-dependent - Elm: `modBy` for divisor-dependent, `remainderBy` for dividend-dependent - Euphoria: `mod` for divisor-dependent, `remainder` for dividend-dependent - Python: `%` for divisor-dependent, `math.fmod` for dividend-dependent - Smalltalk: `\\` for divisor-dependent, `rem:` for dividend-dependent And of course, many don't even expose a type of modulo where the sign matches the divisor. For some examples: - APL - LibreOffice/Excel - Lua - Perl - Mathematica - PL/I - TCL There's also Dart, a relatively new language which defaults to non-negative always. This relatively long list of languages, *despite* C's heritage and semantics being inherited in much of them, makes me question using a function for this, and there would need to be a *lot* of FUD to get people to use the function more than the operator. So this is why I would prefer an operator as opposed to syntax for this. - Isiah Meadows cont...@isiahmeadows.com www.isiahmeadows.com On Thu, Aug 15, 2019 at 3:58 PM Jordan Harband wrote: > > Static functions don't have the same risk as prototype functions; `Math.mod` > would make sense to add. > > One suggestion, though, would be to try to add the API method first, and look > at usage for awhile before trying to add the syntax. > > On Thu, Aug 15, 2019 at 10:12 AM Andrea Giammarchi > wrote: >> >> To me there's no risk, as MooTools, Prototype, and Scriptacolous are both >> things of the past, and never implemented Math.mod ... so, with that >> approach, custom transpiling functions are more dangerous, as somebody might >> have implemented `%%` already for other purposes, and we break Babel outcome >> adding new syntax anyway ... the smoosh accident, is the equivalent of >> custom Babel utilities these days. >> >> Look at TypeScript and the private class fields, if you want to compare new >> syntax instead >> >> On Thu, Aug 15, 2019 at 4:50 PM Michael Haufe >> wrote: >>> >>> Thursday, August 15, 2019 2:47 AM, Andrea Giammarchi wrote: >>> >>> >>> >>> > FWIW another disadvantage is that operators cannot be polyfilled, so >>> > it'll take forever for those not using transpilers to adopt these, while >>> > having a `Math,mod` would work right away >>> >>> >>> >>> >>> >>> With such an approach there is risk of another ‘smooshgate’ [1][2]. There >>> is nothing stopping those developers from using a function anyway to bridge >>> the gap if they can’t or won’t use a compiler. This is already the current >>> state of affairs. >>> >>> >>> >>> [1] https://developers.google.com/web/updates/2018/03/smooshgate >>> >>> [2] >>> https://adamsilver.io/articles/the-disadvantages-of-javascript-polyfills/ >>> >>> >>> >>> Michael >> >> ___ >> 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: Modulo Operator %%
Static functions don't have the same risk as prototype functions; `Math.mod` would make sense to add. One suggestion, though, would be to try to add the API method first, and look at usage for awhile before trying to add the syntax. On Thu, Aug 15, 2019 at 10:12 AM Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > To me there's no risk, as MooTools, Prototype, and Scriptacolous are both > things of the past, and never implemented Math.mod ... so, with that > approach, custom transpiling functions are more dangerous, as somebody > might have implemented `%%` already for other purposes, and we break Babel > outcome adding new syntax anyway ... the smoosh accident, is the equivalent > of custom Babel utilities these days. > > Look at TypeScript and the private class fields, if you want to compare > new syntax instead > > On Thu, Aug 15, 2019 at 4:50 PM Michael Haufe > wrote: > >> Thursday, August 15, 2019 2:47 AM, Andrea Giammarchi wrote: >> >> >> >> > FWIW another disadvantage is that operators cannot be polyfilled, so >> it'll take forever for those not using transpilers to adopt these, while >> having a `Math,mod` would work right away >> >> >> >> >> >> With such an approach there is risk of another ‘smooshgate’ [1][2]. There >> is nothing stopping those developers from using a function anyway to bridge >> the gap if they can’t or won’t use a compiler. This is already the current >> state of affairs. >> >> >> >> [1] https://developers.google.com/web/updates/2018/03/smooshgate >> >> [2] >> https://adamsilver.io/articles/the-disadvantages-of-javascript-polyfills/ >> >> >> >> Michael >> > ___ > 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: Modulo Operator %%
Thursday, August 15, 2019 2:47 AM, Andrea Giammarchi wrote: > FWIW another disadvantage is that operators cannot be polyfilled, so it'll > take forever for those not using transpilers to adopt these, while having a > `Math,mod` would work right away With such an approach there is risk of another ‘smooshgate’ [1][2]. There is nothing stopping those developers from using a function anyway to bridge the gap if they can’t or won’t use a compiler. This is already the current state of affairs. [1] https://developers.google.com/web/updates/2018/03/smooshgate [2] https://adamsilver.io/articles/the-disadvantages-of-javascript-polyfills/ Michael ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.joinWith(iterable)
"weave"? (I've likely missed the purpose of the method)
On Thu, 15 Aug 2019, 18:12 Andrea Giammarchi,
wrote:
> That;s not useful for template literals tags though
>
> _.zip(['a', 'b', 'c'], [1, 2]);
> [["a", 1], ["b", 2], ["c", undefined]]
>
> it basically does nothing I've proposed ... any other name suggestion?
>
> On Thu, Aug 15, 2019 at 3:40 PM Michał Wadas
> wrote:
>
>> https://lodash.com/docs/#zip
>> https://docs.python.org/3/library/functions.html#zip
>>
>> On Thu, 15 Aug 2019, 15:34 Andrea Giammarchi, <
>> andrea.giammar...@gmail.com> wrote:
>>
>>>
>>>1. the suggested name is just ... suggested, I don't have strong
>>>opinion on it, it just `join` values through other values
>>>2. what's `Array.zip` ? I've no idea
>>>
>>>
>>> On Thu, Aug 15, 2019 at 12:53 PM Michał Wadas
>>> wrote:
>>>
I would rather see Array.zip, it covers this use case.
On Thu, 15 Aug 2019, 10:50 Andrea Giammarchi, <
andrea.giammar...@gmail.com> wrote:
>
> I wonder if there's any interest in adding another handy Array method
> as joinWith could be:
>
> ```js
> // proposal example
> Array.prototype.joinWith = function (values) {
> const {length} = this;
> if (length < 2)
> return this.join('');
> const out = [this[0]];
> const len = values.length;
> for (let i = 1; i < length; i++) {
> console.log(i, len);
> out.push(values[(i - 1) % len], this[i]);
> }
> return out.join('');
> };
> ```
>
> The goal is to simplify joining array entries through not the same
> value, example:
>
> ```js
> console.log(['a', 'b', 'c', 'd'].joinWith([1, 2]));
> // a1b2c1d
>
> function tag2str(template, ...values) {
> return template.joinWith(values);
> }
>
> tag2str`a${1}b${2}c`;
> // "a1b2c"
> ```
>
> Throughts?
> ___
> 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: Modulo Operator %%
On 8/14/19 7:50 PM, Waldemar Horwat wrote: > And I'm saying that's potentially problematic because it changes the meaning > of existing programs that happen to use "mod" as a variable name. The above > is one example that would turn a let statement into a mod expression. Here's > another example: > > x = 4 > mod(foo) Potentially yes and surely there is a yacc definition where one could check to be certain? Regardless, let's assume there is or that workarounds to guarantee infixity are not worth the complication ([no LineTerminator here] usage). We know that syntax is the last bastion of language luddites, so it's best not to linger on something which was not my main concern. I am more interested in maintaining the duality of the operators over how they are represented (within reason). Thus, if '%%' is what is preferable, then '\\' would be the partner. Michael ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modulo Operator %%
Fair points, but since `**` has its `Math.pow` counter part, why wouldn't `%%` have `Math.mod` as counterpart too? At least it looks like there's room for both, if standardized, as the behavior and description would likely be mostly the same (precedence a part) On Thu, Aug 15, 2019 at 7:13 PM Isiah Meadows wrote: > An operator is far more concise than a function call, and is likely to > see greater use. It also aligns better with peoples' intuition on what > the "modulus" is, avoiding subtle bugs like in `isOdd = x => x % 2 === > 1` (example from > https://en.wikipedia.org/wiki/Modulo_operation#Common_pitfalls - try > passing a negative to it). And given this one is high value (see > above) and *very* low cost (it can literally desugar to `(x % y + y) % > y`), I feel it does meet that bar. > > > It would be interesting to hear the feedback of those that use regularly > powers, whether the benefit was clear (personally, I almost never use > either `Math.pow()` or `**`, so that I can’t say anything). > > It has enough benefit I've seen CoffeeScript users default to `%%` and > only using `%` when they explicitly want the dividend-dependent > semantics. And engines with a native `%%`, if they can detect the > operands are always non-negative, can optimize it to `%` pretty > easily. It's better *enough* that you'd likely start seeing some > partially legitimate FUD spread about the standard `%`. > > One other added benefit of using divisor-dependent modulo is that `x > %% (2**n)`, where `x` and `n` are integers and `n >= 0`, could always > be safely rewritten to `x & (2**n - 1)` while still preserving > semantics, but `x % (2**n)` does *not* have this property. For > example: > > - `-1 %% (2**1)` → `-1 %% 1` → `1` > - `-1 & (2**1 - 1)` → `-1 & 1` → `1` > - `-1 % (2**1)` → `-1 % 2` → `-1` > > BTW, I literally tested all three of these in Chrome's devtools > console, using my `x %% y` → `(x % y + y) % y` desugaring. > > As for a native implementation and the spec, I'd recommend just doing > `copysign(fmod(x, y), y)` instead to retain precision. > > > At least one disadvantage of an operator over a function, is that you > have to think about precedence. The problem is exacerbated in JS, because > (following some other languages) the unary minus has an uncanny high > precedence level, confusingly very different than the one of the binary > minus; so that, after having designed `**`, it was realised at the last > minute that `-a**b` would be dumbly interpreted as `(-a)**b` instead of > `-(a**b)` or `0-a**b`, as anybody who would be likely to actually use the > operator would expect. (That particular issue was resolved in a hurry by > making the parenthesis-left form a syntax error.) > > I doubt this would happen with `%%`. It's similar enough to the > existing `%` in concept that most would expect it to have the same > precedence. With `**`, there was a very unique issue with it: there > were people actually *reading* it both ways, and even a language > (Python) that interprets `-a ** b` and `-a**b` *differently* in light > of that (as `(-a) ** b` and `-(a ** b)` respectively). That's not a > concern at all with most operators, so it doesn't apply to most new > operator proposals. > > - > > Isiah Meadows > cont...@isiahmeadows.com > www.isiahmeadows.com > On Thu, Aug 15, 2019 at 2:40 AM Claude Pache > wrote: > > > > > > > > Le 12 août 2019 à 22:00, Matthew Morgan a > écrit : > > > > > JS needs a modulo operator. It currently has the remainder operator > `%` which works in most cases except for negative values. I believe the the > `%%` would work great and be easy to remember. > > > > > > let x = (-13) %% 64; > > > is equivalent to > > > let x = ((-13 % 64) + 64) % 64; > > > > > > Is there a strong advantage of an `%%` operator over a `Math.mod()` > function? There is the precedent of the `**` operator implemented as > alternative of `Math.pow()` few years ago. It would be interesting to hear > the feedback of those that use regularly powers, whether the benefit was > clear (personally, I almost never use either `Math.pow()` or `**`, so that > I can’t say anything). > > > > At least one disadvantage of an operator over a function, is that you > have to think about precedence. The problem is exacerbated in JS, because > (following some other languages) the unary minus has an uncanny high > precedence level, confusingly very different than the one of the binary > minus; so that, after having designed `**`, it was realised at the last > minute that `-a**b` would be dumbly interpreted as `(-a)**b` instead of > `-(a**b)` or `0-a**b`, as anybody who would be likely to actually use the > operator would expect. (That particular issue was resolved in a hurry by > making the parenthesis-left form a syntax error.) > > > > —Claude > > > > ___ > > es-discuss mailing list > > es-discuss@mozilla.org > > https://mail.mozilla.org/listinfo/es-discuss >
Re: Modulo Operator %%
An operator is far more concise than a function call, and is likely to see greater use. It also aligns better with peoples' intuition on what the "modulus" is, avoiding subtle bugs like in `isOdd = x => x % 2 === 1` (example from https://en.wikipedia.org/wiki/Modulo_operation#Common_pitfalls - try passing a negative to it). And given this one is high value (see above) and *very* low cost (it can literally desugar to `(x % y + y) % y`), I feel it does meet that bar. > It would be interesting to hear the feedback of those that use regularly > powers, whether the benefit was clear (personally, I almost never use either > `Math.pow()` or `**`, so that I can’t say anything). It has enough benefit I've seen CoffeeScript users default to `%%` and only using `%` when they explicitly want the dividend-dependent semantics. And engines with a native `%%`, if they can detect the operands are always non-negative, can optimize it to `%` pretty easily. It's better *enough* that you'd likely start seeing some partially legitimate FUD spread about the standard `%`. One other added benefit of using divisor-dependent modulo is that `x %% (2**n)`, where `x` and `n` are integers and `n >= 0`, could always be safely rewritten to `x & (2**n - 1)` while still preserving semantics, but `x % (2**n)` does *not* have this property. For example: - `-1 %% (2**1)` → `-1 %% 1` → `1` - `-1 & (2**1 - 1)` → `-1 & 1` → `1` - `-1 % (2**1)` → `-1 % 2` → `-1` BTW, I literally tested all three of these in Chrome's devtools console, using my `x %% y` → `(x % y + y) % y` desugaring. As for a native implementation and the spec, I'd recommend just doing `copysign(fmod(x, y), y)` instead to retain precision. > At least one disadvantage of an operator over a function, is that you have to > think about precedence. The problem is exacerbated in JS, because (following > some other languages) the unary minus has an uncanny high precedence level, > confusingly very different than the one of the binary minus; so that, after > having designed `**`, it was realised at the last minute that `-a**b` would > be dumbly interpreted as `(-a)**b` instead of `-(a**b)` or `0-a**b`, as > anybody who would be likely to actually use the operator would expect. (That > particular issue was resolved in a hurry by making the parenthesis-left form > a syntax error.) I doubt this would happen with `%%`. It's similar enough to the existing `%` in concept that most would expect it to have the same precedence. With `**`, there was a very unique issue with it: there were people actually *reading* it both ways, and even a language (Python) that interprets `-a ** b` and `-a**b` *differently* in light of that (as `(-a) ** b` and `-(a ** b)` respectively). That's not a concern at all with most operators, so it doesn't apply to most new operator proposals. - Isiah Meadows cont...@isiahmeadows.com www.isiahmeadows.com On Thu, Aug 15, 2019 at 2:40 AM Claude Pache wrote: > > > > Le 12 août 2019 à 22:00, Matthew Morgan a écrit : > > > JS needs a modulo operator. It currently has the remainder operator `%` > > which works in most cases except for negative values. I believe the the > > `%%` would work great and be easy to remember. > > > > let x = (-13) %% 64; > > is equivalent to > > let x = ((-13 % 64) + 64) % 64; > > > Is there a strong advantage of an `%%` operator over a `Math.mod()` function? > There is the precedent of the `**` operator implemented as alternative of > `Math.pow()` few years ago. It would be interesting to hear the feedback of > those that use regularly powers, whether the benefit was clear (personally, I > almost never use either `Math.pow()` or `**`, so that I can’t say anything). > > At least one disadvantage of an operator over a function, is that you have to > think about precedence. The problem is exacerbated in JS, because (following > some other languages) the unary minus has an uncanny high precedence level, > confusingly very different than the one of the binary minus; so that, after > having designed `**`, it was realised at the last minute that `-a**b` would > be dumbly interpreted as `(-a)**b` instead of `-(a**b)` or `0-a**b`, as > anybody who would be likely to actually use the operator would expect. (That > particular issue was resolved in a hurry by making the parenthesis-left form > a syntax error.) > > —Claude > > ___ > 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: Array.prototype.joinWith(iterable)
That;s not useful for template literals tags though
_.zip(['a', 'b', 'c'], [1, 2]);
[["a", 1], ["b", 2], ["c", undefined]]
it basically does nothing I've proposed ... any other name suggestion?
On Thu, Aug 15, 2019 at 3:40 PM Michał Wadas wrote:
> https://lodash.com/docs/#zip
> https://docs.python.org/3/library/functions.html#zip
>
> On Thu, 15 Aug 2019, 15:34 Andrea Giammarchi,
> wrote:
>
>>
>>1. the suggested name is just ... suggested, I don't have strong
>>opinion on it, it just `join` values through other values
>>2. what's `Array.zip` ? I've no idea
>>
>>
>> On Thu, Aug 15, 2019 at 12:53 PM Michał Wadas
>> wrote:
>>
>>> I would rather see Array.zip, it covers this use case.
>>>
>>> On Thu, 15 Aug 2019, 10:50 Andrea Giammarchi, <
>>> andrea.giammar...@gmail.com> wrote:
>>>
I wonder if there's any interest in adding another handy Array method
as joinWith could be:
```js
// proposal example
Array.prototype.joinWith = function (values) {
const {length} = this;
if (length < 2)
return this.join('');
const out = [this[0]];
const len = values.length;
for (let i = 1; i < length; i++) {
console.log(i, len);
out.push(values[(i - 1) % len], this[i]);
}
return out.join('');
};
```
The goal is to simplify joining array entries through not the same
value, example:
```js
console.log(['a', 'b', 'c', 'd'].joinWith([1, 2]));
// a1b2c1d
function tag2str(template, ...values) {
return template.joinWith(values);
}
tag2str`a${1}b${2}c`;
// "a1b2c"
```
Throughts?
___
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: Modulo Operator %%
To me there's no risk, as MooTools, Prototype, and Scriptacolous are both things of the past, and never implemented Math.mod ... so, with that approach, custom transpiling functions are more dangerous, as somebody might have implemented `%%` already for other purposes, and we break Babel outcome adding new syntax anyway ... the smoosh accident, is the equivalent of custom Babel utilities these days. Look at TypeScript and the private class fields, if you want to compare new syntax instead On Thu, Aug 15, 2019 at 4:50 PM Michael Haufe wrote: > Thursday, August 15, 2019 2:47 AM, Andrea Giammarchi wrote: > > > > > FWIW another disadvantage is that operators cannot be polyfilled, so > it'll take forever for those not using transpilers to adopt these, while > having a `Math,mod` would work right away > > > > > > With such an approach there is risk of another ‘smooshgate’ [1][2]. There > is nothing stopping those developers from using a function anyway to bridge > the gap if they can’t or won’t use a compiler. This is already the current > state of affairs. > > > > [1] https://developers.google.com/web/updates/2018/03/smooshgate > > [2] > https://adamsilver.io/articles/the-disadvantages-of-javascript-polyfills/ > > > > Michael > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modulo Operator %%
We could circumvent this by making `%%` analogous to `**`. That is, we could provide a function form `Math.mod` as well as an infix operator `%%`. On Thursday, August 15, 2019 9:46:57 AM CEST Andrea Giammarchi wrote: > FWIW another disadvantage is that operators cannot be polyfilled, so it'll > take forever for those not using transpilers to adopt these, while having a > `Math,mod` would work right away > > On Thu, Aug 15, 2019 at 8:40 AM Claude Pache wrote: > > Le 12 août 2019 à 22:00, Matthew Morgan a écrit : > > > > JS needs a modulo operator. It currently has the remainder operator `%` > > which works in most cases except for negative values. I believe the the > > `%%` would work great and be easy to remember. > > > > let x = (-13) %% 64; > > is equivalent to > > let x = ((-13 % 64) + 64) % 64; > > > > > > Is there a strong advantage of an `%%` operator over a `Math.mod()` > > function? There is the precedent of the `**` operator implemented as > > alternative of `Math.pow()` few years ago. It would be interesting to hear > > the feedback of those that use regularly powers, whether the benefit was > > clear (personally, I almost never use either `Math.pow()` or `**`, so that > > I can’t say anything). > > > > At least one disadvantage of an operator over a function, is that you have > > to think about precedence. The problem is exacerbated in JS, because > > (following some other languages) the unary minus has an uncanny high > > precedence level, confusingly very different than the one of the binary > > minus; so that, after having designed `**`, it was realised at the last > > minute that `-a**b` would be dumbly interpreted as `(-a)**b` instead of > > `-(a**b)` or `0-a**b`, as anybody who would be likely to actually use the > > operator would expect. (That particular issue was resolved in a hurry by > > making the parenthesis-left form a syntax error.) > > > > —Claude > > > > ___ > > es-discuss mailing list > > es-discuss@mozilla.org > > https://mail.mozilla.org/listinfo/es-discuss signature.asc Description: This is a digitally signed message part. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.joinWith(iterable)
https://lodash.com/docs/#zip
https://docs.python.org/3/library/functions.html#zip
On Thu, 15 Aug 2019, 15:34 Andrea Giammarchi,
wrote:
>
>1. the suggested name is just ... suggested, I don't have strong
>opinion on it, it just `join` values through other values
>2. what's `Array.zip` ? I've no idea
>
>
> On Thu, Aug 15, 2019 at 12:53 PM Michał Wadas
> wrote:
>
>> I would rather see Array.zip, it covers this use case.
>>
>> On Thu, 15 Aug 2019, 10:50 Andrea Giammarchi, <
>> andrea.giammar...@gmail.com> wrote:
>>
>>>
>>> I wonder if there's any interest in adding another handy Array method as
>>> joinWith could be:
>>>
>>> ```js
>>> // proposal example
>>> Array.prototype.joinWith = function (values) {
>>> const {length} = this;
>>> if (length < 2)
>>> return this.join('');
>>> const out = [this[0]];
>>> const len = values.length;
>>> for (let i = 1; i < length; i++) {
>>> console.log(i, len);
>>> out.push(values[(i - 1) % len], this[i]);
>>> }
>>> return out.join('');
>>> };
>>> ```
>>>
>>> The goal is to simplify joining array entries through not the same
>>> value, example:
>>>
>>> ```js
>>> console.log(['a', 'b', 'c', 'd'].joinWith([1, 2]));
>>> // a1b2c1d
>>>
>>> function tag2str(template, ...values) {
>>> return template.joinWith(values);
>>> }
>>>
>>> tag2str`a${1}b${2}c`;
>>> // "a1b2c"
>>> ```
>>>
>>> Throughts?
>>> ___
>>> 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: Array.prototype.joinWith(iterable)
1. the suggested name is just ... suggested, I don't have strong opinion
on it, it just `join` values through other values
2. what's `Array.zip` ? I've no idea
On Thu, Aug 15, 2019 at 12:53 PM Michał Wadas wrote:
> I would rather see Array.zip, it covers this use case.
>
> On Thu, 15 Aug 2019, 10:50 Andrea Giammarchi,
> wrote:
>
>>
>> I wonder if there's any interest in adding another handy Array method as
>> joinWith could be:
>>
>> ```js
>> // proposal example
>> Array.prototype.joinWith = function (values) {
>> const {length} = this;
>> if (length < 2)
>> return this.join('');
>> const out = [this[0]];
>> const len = values.length;
>> for (let i = 1; i < length; i++) {
>> console.log(i, len);
>> out.push(values[(i - 1) % len], this[i]);
>> }
>> return out.join('');
>> };
>> ```
>>
>> The goal is to simplify joining array entries through not the same value,
>> example:
>>
>> ```js
>> console.log(['a', 'b', 'c', 'd'].joinWith([1, 2]));
>> // a1b2c1d
>>
>> function tag2str(template, ...values) {
>> return template.joinWith(values);
>> }
>>
>> tag2str`a${1}b${2}c`;
>> // "a1b2c"
>> ```
>>
>> Throughts?
>> ___
>> 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: Array.prototype.joinWith(iterable)
I would rather see Array.zip, it covers this use case.
On Thu, 15 Aug 2019, 10:50 Andrea Giammarchi,
wrote:
>
> I wonder if there's any interest in adding another handy Array method as
> joinWith could be:
>
> ```js
> // proposal example
> Array.prototype.joinWith = function (values) {
> const {length} = this;
> if (length < 2)
> return this.join('');
> const out = [this[0]];
> const len = values.length;
> for (let i = 1; i < length; i++) {
> console.log(i, len);
> out.push(values[(i - 1) % len], this[i]);
> }
> return out.join('');
> };
> ```
>
> The goal is to simplify joining array entries through not the same value,
> example:
>
> ```js
> console.log(['a', 'b', 'c', 'd'].joinWith([1, 2]));
> // a1b2c1d
>
> function tag2str(template, ...values) {
> return template.joinWith(values);
> }
>
> tag2str`a${1}b${2}c`;
> // "a1b2c"
> ```
>
> Throughts?
> ___
> 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: Where is the evaluation starting point in the spec?
On 2019-08-15 10:53, Alan Schmitt writes: Back in ES5.1, there was a specification to evaluate programs (https://www.ecma-international.org/ecma-262/5.1/index.html#sec-14). What is the corresponding starting point in the current spec? Is it https://tc39.es/ecma262/#sec-scripts ? Thanks to the handy Reference links in the spec, I found it: https://tc39.es/ecma262/#sec-runjobs Sorry for the noise. Best, Alan signature.asc Description: PGP signature ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Where is the evaluation starting point in the spec?
Hello, Back in ES5.1, there was a specification to evaluate programs (https://www.ecma-international.org/ecma-262/5.1/index.html#sec-14). What is the corresponding starting point in the current spec? Is it https://tc39.es/ecma262/#sec-scripts ? Best, Alan signature.asc Description: PGP signature ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Array.prototype.joinWith(iterable)
I wonder if there's any interest in adding another handy Array method as
joinWith could be:
```js
// proposal example
Array.prototype.joinWith = function (values) {
const {length} = this;
if (length < 2)
return this.join('');
const out = [this[0]];
const len = values.length;
for (let i = 1; i < length; i++) {
console.log(i, len);
out.push(values[(i - 1) % len], this[i]);
}
return out.join('');
};
```
The goal is to simplify joining array entries through not the same value,
example:
```js
console.log(['a', 'b', 'c', 'd'].joinWith([1, 2]));
// a1b2c1d
function tag2str(template, ...values) {
return template.joinWith(values);
}
tag2str`a${1}b${2}c`;
// "a1b2c"
```
Throughts?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Modulo Operator %%
Is there any way we can add function/operator equivalence to the language? Perhaps some kind of 'operators' global object with symbol fields matching operator string to functions/constraints? -- Dammit babies, you've got to be kind. On Thu, 15 Aug 2019 at 08:47, Andrea Giammarchi wrote: > FWIW another disadvantage is that operators cannot be polyfilled, so it'll > take forever for those not using transpilers to adopt these, while having a > `Math,mod` would work right away > > On Thu, Aug 15, 2019 at 8:40 AM Claude Pache > wrote: > >> >> >> Le 12 août 2019 à 22:00, Matthew Morgan a écrit >> : >> >> JS needs a modulo operator. It currently has the remainder operator `%` >> which works in most cases except for negative values. I believe the the >> `%%` would work great and be easy to remember. >> >> let x = (-13) %% 64; >> is equivalent to >> let x = ((-13 % 64) + 64) % 64; >> >> >> Is there a strong advantage of an `%%` operator over a `Math.mod()` >> function? There is the precedent of the `**` operator implemented as >> alternative of `Math.pow()` few years ago. It would be interesting to hear >> the feedback of those that use regularly powers, whether the benefit was >> clear (personally, I almost never use either `Math.pow()` or `**`, so that >> I can’t say anything). >> >> At least one disadvantage of an operator over a function, is that you >> have to think about precedence. The problem is exacerbated in JS, because >> (following some other languages) the unary minus has an uncanny high >> precedence level, confusingly very different than the one of the binary >> minus; so that, after having designed `**`, it was realised at the last >> minute that `-a**b` would be dumbly interpreted as `(-a)**b` instead of >> `-(a**b)` or `0-a**b`, as anybody who would be likely to actually use the >> operator would expect. (That particular issue was resolved in a hurry by >> making the parenthesis-left form a syntax error.) >> >> —Claude >> >> ___ >> 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: Modulo Operator %%
FWIW another disadvantage is that operators cannot be polyfilled, so it'll take forever for those not using transpilers to adopt these, while having a `Math,mod` would work right away On Thu, Aug 15, 2019 at 8:40 AM Claude Pache wrote: > > > Le 12 août 2019 à 22:00, Matthew Morgan a écrit : > > JS needs a modulo operator. It currently has the remainder operator `%` > which works in most cases except for negative values. I believe the the > `%%` would work great and be easy to remember. > > let x = (-13) %% 64; > is equivalent to > let x = ((-13 % 64) + 64) % 64; > > > Is there a strong advantage of an `%%` operator over a `Math.mod()` > function? There is the precedent of the `**` operator implemented as > alternative of `Math.pow()` few years ago. It would be interesting to hear > the feedback of those that use regularly powers, whether the benefit was > clear (personally, I almost never use either `Math.pow()` or `**`, so that > I can’t say anything). > > At least one disadvantage of an operator over a function, is that you have > to think about precedence. The problem is exacerbated in JS, because > (following some other languages) the unary minus has an uncanny high > precedence level, confusingly very different than the one of the binary > minus; so that, after having designed `**`, it was realised at the last > minute that `-a**b` would be dumbly interpreted as `(-a)**b` instead of > `-(a**b)` or `0-a**b`, as anybody who would be likely to actually use the > operator would expect. (That particular issue was resolved in a hurry by > making the parenthesis-left form a syntax error.) > > —Claude > > ___ > 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: Modulo Operator %%
> Le 12 août 2019 à 22:00, Matthew Morgan a écrit : > > JS needs a modulo operator. It currently has the remainder operator `%` which > works in most cases except for negative values. I believe the the `%%` would > work great and be easy to remember. > > let x = (-13) %% 64; > is equivalent to > let x = ((-13 % 64) + 64) % 64; Is there a strong advantage of an `%%` operator over a `Math.mod()` function? There is the precedent of the `**` operator implemented as alternative of `Math.pow()` few years ago. It would be interesting to hear the feedback of those that use regularly powers, whether the benefit was clear (personally, I almost never use either `Math.pow()` or `**`, so that I can’t say anything). At least one disadvantage of an operator over a function, is that you have to think about precedence. The problem is exacerbated in JS, because (following some other languages) the unary minus has an uncanny high precedence level, confusingly very different than the one of the binary minus; so that, after having designed `**`, it was realised at the last minute that `-a**b` would be dumbly interpreted as `(-a)**b` instead of `-(a**b)` or `0-a**b`, as anybody who would be likely to actually use the operator would expect. (That particular issue was resolved in a hurry by making the parenthesis-left form a syntax error.) —Claude ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
