gardnerjohng at gmail.com (2016-01-24T06:15:11.622Z)
> *This has all the benefits you seek, including visual clarity, without > overloading the meaning of an existing token.* Actually, I beg to differ. Recall that this is valid syntax: ```js 1.. toString(16); ``` Furthermore, maintaining a 3-dot notation stays consistent with the rest and spread operators, both of which already overload each other. For sake of clarity for this discussion, I'll call this one the "range operator". > *I think this is one of those issues where the benefit of any new syntax > here does not pay for its complexity costs.* I don't foresee this raising any complexity issues. The syntax is intended chiefly as a way to specify multiple integers where indexed access is relevant. There wouldn't be any need to specify exclusive or inclusive expansion, because it'd always work inclusively. Which is what I believe every author would expect when they write `1 ... 5`. It would also enable one to write this: ```js func( 0 ... 5 ) ``` Instead of this: ```js func( ...[0, 1, 2, 3, 4, 5] ); ``` I can't speak on anybody else's behalf, but I know which of the two I'd prefer writing. Again, I'll state I don't expect this to be a groundbreaking feature. But it's simple, clean and (from what I understand) would be unintrusive to the language.
gardnerjohng at gmail.com (2016-01-24T06:14:20.367Z)
> *This has all the benefits you seek, including visual clarity, without > overloading the meaning of an existing token.* Actually, I beg to differ. Recall that this is valid syntax: ```js 1.. toString(16); ``` Furthermore, maintaining a 3-dot notation stays consistent with the rest and spread operators, both of which already overload each other. For sake of clarity for this discussion, I'll call this one the "range operator". > *I think this is one of those issues where the benefit of any new syntax > here does not pay for its complexity costs.* I don't foresee this raising any complexity issues. The syntax is intended chiefly as a way to specify multiple integer ranges where indexed access is relevant. There wouldn't be any need to specify exclusive or inclusive expansion, because it'd always work inclusively. Which is what I believe every author would expect when they write `1 ... 5`. It would also enable one to write this: ```js func( 0 ... 5 ) ``` Instead of this: ```js func( ...[0, 1, 2, 3, 4, 5] ); ``` I can't speak on anybody else's behalf, but I know which of the two I'd prefer writing. Again, I'll state I don't expect this to be a groundbreaking feature. But it's simple, clean and (from what I understand) would be unintrusive to the language.
gardnerjohng at gmail.com (2016-01-24T06:13:19.619Z)
> *This has all the benefits you seek, including visual clarity, without > overloading the meaning of an existing token.* Actually, I beg to differ. Recall that this is valid syntax: ```js 1.. toString(16); ``` Furthermore, maintaining a 3-dot notation stays consistent with the rest and spread operators, both of which already overload each other. For sake of clarity for this discussion, I'll call this one the "range operator". *I think this is one of those issues where the benefit of any new syntax > here does not pay for its complexity costs.* I don't foresee this raising any complexity issues. The syntax is intended chiefly as a way to specify multiple integer ranges where indexed access is relevant. There wouldn't be any need to specify exclusive or inclusive expansion, because it'd always work inclusively. Which is what I believe every author would expect when they write 1 ... 5. It would also enable one to write this: ```js func( 0 ... 5 ) ``` Instead of this: ```js func( ...[0, 1, 2, 3, 4, 5] ); ``` I can't speak on anybody else's behalf, but I know which of the two I'd prefer writing. Again, I'll state I don't expect this to be a groundbreaking feature. But it's simple, clean and (from what I understand) would be unintrusive to the language.
> > *This has all the benefits you seek, including visual clarity, without > overloading the meaning of an existing token.* Actually, I beg to differ. Recall that this is valid syntax: 1.. toString(16); Furthermore, maintaining a 3-dot notation stays consistent with the rest and spread operators, both of which already overload each other. For sake of clarity for this discussion, I'll call this one the "range operator". *I think this is one of those issues where the benefit of any new syntax > here does not pay for its complexity costs.* I don't foresee this raising any complexity issues. The syntax is intended chiefly as a way to specify multiple integer ranges where indexed access is relevant. There wouldn't be any need to specify exclusive or inclusive expansion, because it'd always work inclusively. Which is what I believe every author would expect when they write 1 ... 5. It would also enable one to write this: func( 0 ... 5 ) Instead of this: func( ...[0, 1, 2, 3, 4, 5] ); I can't speak on anybody else's behalf, but I know which of the two I'd prefer writing. Again, I'll state I don't expect this to be a groundbreaking feature. But it's simple, clean and (from what I understand) would be unintrusive to the language. On 24 January 2016 at 05:41, Mark S. Miller <erights at google.com> wrote: > The double dot ("..") is the traditional infix operator for > inclusive,inclusive integer ranges, going back to Pascal (the language, not > the mathematician). This has all the benefits you seek, including visual > clarity, without overloading the meaning of an existing token. > > Whether double or triple dot, the problem is that programming patterns in > zero-index-origin languages want inclusive,exclusive ranges, which > naturally wants an asymmetric syntax to suggest the distinction. The > traditional math notation [0, 4) would be unambiguous, since of course we > never otherwise allow a closing paren to match an opening square bracket. > But, in a programming language context I find it too jarring. > > E has ".." for inclusive,inclusive ranges, just like Pascal. E also has > "..!" for inclusive,exclusive ranges. The second operator was used much > more than the first. I don't think "..!" is great but I don't have anything > better to suggest. > > Finally, we must ask whether this problem is worth solving with any syntax > or at all. We can already express these well enough with APIs. I think this > is one of those issues where the benefit of any new syntax here does not > pay for its complexity costs. See *The Tragedy of the Common Lisp, or, > Why Large Languages Explode* < > https://esdiscuss.org/topic/the-tragedy-of-the-common-lisp-or-why-large-languages-explode-was-revive-let-blocks > >. > > See also <https://en.wikipedia.org/wiki/Primum_non_nocere>. > > > > > > > On Fri, Jan 22, 2016 at 10:20 PM, John Gardner <gardnerjohng at gmail.com> > wrote: > >> Probably a stupid idea, and I can see it already being brought up several >> times... but why not extend spread operators to work with numeric ranges? >> >> let a = [ 0 ... 3 ]; >> // Expands to: [ 0, 1, 2, 3 ] >> >> This wouldn't be a groundbreaking feature, but it would allow better >> readability when plotting a range of values: >> >> let esVersions = [ 1 ... 5, 2015 ]; >> >> It might also be used to extract a range of values: >> >> array[ 3 ... 6 ] = "ABCDEFGH"; >> // [ "D", "E", "F", "G" ] >> >> Which I find far more readable than this: >> >> array[ , , , , 3, 4, 5, 6 ] = "ABCDEFGH"; >> >> Since it would require two numbers to be explicitly supplied on each >> side, there's no risk of it being misinterpreted as an attempt to spread an >> array. Decimal components would be dropped: >> >> let a = [ 1 ... 3.9 ]; >> // [ 1, 2, 3 ] >> >> This would complement Alican's suggested syntax for slicing an array of >> values, which modifies the original array. >> >> Thoughts? Just throwing crap out there. >> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > > -- > Cheers, > --MarkM > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160124/6ba304ff/attachment-0001.html>