The range operator wouldn't attempt to fill every duty that a Python-like `range` function would. I'd envision it being kept intentionally simple (no custom steps, for example). It looks like what it does, and there's no reason the two couldn't co-exist.
*can't make mistake (consider [a...b] vs. [a,...b] - is it easy to see > difference?)* That's a non-argument pertaining to an author's formatting choice. On 24 January 2016 at 23:13, Michał Wadas <[email protected]> wrote: > I want to ask why new syntax would be better than Python-like `range` > function? > > Cons of range: > - normal function rather than new syntax > - can be used as memory efficient generator > - custom step can be defined > - easy to polyfill > - can't make mistake (consider [a...b] vs. [a,...b] - is it easy to see > difference?) > > Disadvantages: > - longer than custom syntax > On 24 Jan 2016 7:11 am, "John Gardner" <[email protected]> wrote: > >> *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 <[email protected]> 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 <[email protected]> >>> 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 >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>> >>> >>> -- >>> Cheers, >>> --MarkM >>> >> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >>
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
