Re: Proposal of Multithread JavaScript

[Leo Dutra]

Why would UI/DOM access need to be serialized?

And Windows is a great reference of what not to do.  .NET as a whole too,
since all before C# 6 comes from bad MS and all after is copied from
somewhere. NT should be thrown away and be replaced by a sweet BSD layer
The only thing they did well are Registered I/O.

Threads are not that good in Linux because a process starup in Linux is
blazing fast... And the work are not that great; except when you have a
thread pool, and a process pool is quite not possible (at least I've never
seen one for general application software).

Hard work is not a reason to discard a gamechanging enhancement.

There's many enterprises which prohibit devs from using threads and some
other language features... They presume retard devs.

A bad developer is not JavaScript issue. A JavaScript issue is the
impossibility of doing something Java, C, C#, Python, Scala, Haskell, Go
and a bunch more do with a simple keyword or method.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Michael J. Ryan]

Workers define a clear boundary...  In Windows, only the main thread can
touch the ui..  and in Linux, threads are almost as expensive as
processes...

Just the same, I'm okay with threads, but feel that not having shared state
I'd better as you will avoid a large amount of potential bugs.  Having
clear separation still allows you to solve many problems where threading
would help in a clean and clear way.

There's been other discussions of a load a threaded module, which could
have a clear line in the sand.  I wouldn't even mind coroutines or a good,
safe csp implementation...  However, those lines would take longer to
develop safely and take longer still to lock down appropriately.

Having worked as threads and allowing a lighter weight message would negate
a lot of the negatives you mention... It doesn't have to be a serialized
message.  Adding an immutable object probative would do the trick (given
fewer hurdles).

All ui/Dom access needs to be serialized anyway, I don't think that's a
good example of why we absolutely need shared state threads.

On Nov 3, 2016 12:19 PM, "Leo Dutra"  wrote:

> I have defined many times, but you guys are in love with workers.
>
> A little look in Java's Runnables would demonstrate de nature and
> difference I'm bringing to this thread.
>
> Workers can't even modify DOM directly...
>
> Very different of go routines, Java/Scala threads etc.
>
> Workers require way more control and coding by the nature of their
> declaration and messaging. A worker lives and awaits... A thread is run
> against a living spawned process and is garbaged after the usage.
>
> ___
> 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: Ranges

[Zach Lym]

With regard to syntax, Rust's is the best that I've seen: '0 ... 10'
inclusive and  '1 .. 9' exclusive.

> for ( i of [1..10] )  { ... }

Why do we need to clutter the syntax with brackets?

Strings are something that's needed, I've been tinkering with a LINQ syntax
for IndexedDB and a Range type would make it easier to take advantage of
indexing.

However, there is not right answer here: is "10A" > "001B"?  What if I'm
storing DNS labels, where `mail.example.com` < `*.example.com`?

I think there should be a sane default (perhaps with syntactic sugar to
specify region encoding and Unicode normalization) but just people to
create extend a Range object so they can build their own semantics.

Thank you,
-Zach Lym

On Thu, Nov 3, 2016 at 2:26 PM, kdex  wrote:

> I don't think we should give the Latin alphabet special treatment. This is
> solely about Unicode codepoints.
>
> I'd expect…
>
> - `String.range("AAA", "ZZZ")` to generate ["AAA", "AAB", …,
> "ABA", … "ZZZ"].
> - `String.range("", "zzz")` to either throw or be equivalent to
> `String.range("\u", "zzz")`.
> - `String.range("z", "A")` to either throw or wrap around at
> "\u{ff}" and therefore include
> all codepoints.
> - `String.range("A", "z")` to include symbols, too. If you only
> need letters in latin-1, you should
> either write a custom latin-1 generator or skip these
> values with a RegExp when iterating
> over them. Or just use two ranges, one for A-Z and one for
> a-z.
> - `String.range("A", "π")` to include all characters from "\u0065"
> (A) to "\u03c0" (π).
> - `String.range("", "")` to generate ["", "", "", ""]
> (surrogate pairs being respected)
>
> For more complicated cases, it might make more sense to make users pass a
> function to `String.range`
> for fine-grained control, or maybe just make users create their own
> generators.
>
> On Thursday, November 3, 2016 8:54:16 PM CET you wrote:
> > Could we just *not* have a `String.range`?
> >
> > 1. Needing a list of alphabetically sorted characters is a bit niche,
> even
> > in the Latin alphabet.
> > 2. It's ambiguous whether it should include symbols or not. (think:
> > `String.range("A", "z")`)
> > 3. If it's Unicode-aware, how should it act with, say, `String.range("A",
> > "π")`?
> >
> > On Thu, Nov 3, 2016, 16:21 Viktor Kronvall 
> > wrote:
> >
> > > Even more interestingly what would `String.range("","zzz")` produce.
> From
> > > what code point is the range started? Will this throw? Is the empty
> string
> > > included in the iterator?
> > > 2016年11月3日(木) 21:18 Viktor Kronvall :
> > >
> > > Actually, after giving it some more thought for that case there is just
> > > that one possibility that makes sense.
> > >
> > > However, there are more ambiguous cases such as `String.range("AAA",
> > > "ZZZ")` (should all letters increase at once or should the rightmost
> letter
> > > be incremented first)
> > >
> > > Also, how would range handle the arguments in inverted order? Should
> there
> > > be a decreasing range or should it terminate with no elements in the
> > > iterator?
> > > 2016年11月3日(木) 21:05 kdex :
> > >
> > > About the code points: `String.range` should also handle surrogate
> pairs,
> > > similar to for..of does it.
> > > About `String.range("A", "zzz")`: Do any other possibilities even make
> > > sense?
> > >
> > > On Thursday, November 3, 2016 6:47:04 PM CET Viktor Kronvall wrote:
> > > > For `String.range` what would the expected result of
> > > > `String.range('A','zzz')` be?
> > > >
> > > > Is an exhaustive pattern expected?
> > > >
> > > > `['A','B','C',...'Z','a','b','c',...,'z','AA','AB',...]`
> > > > 2016年11月3日(木) 19:21 Michael J. Ryan :
> > > >
> > > > > If there's a Number.range, if suggest a corresponding String.range
> for
> > > > > character ranges...  Agreed on it being a utility function over me
> > > syntax.
> > > > >
> > > > > On Nov 3, 2016 10:25 AM, "Isiah Meadows" 
> > > wrote:
> > > > >
> > > > > If string ranges are based on character codes, it will (for the
> Latin
> > > > > alphabet, at least, not necessarily for other languages).
> > > > >
> > > > > I would prefer a function over syntax, though, since it would be
> more
> > > > > easily adopted (polyfill > syntax), and it would fit more
> idiomatically
> > > > > with the rest of the language (which also uses functions for most
> > > > > utilities).
> > > > >
> > > > > Maybe a `Number.range` would work?
> > > > >
> > > > > ```js
> > > > > Number.range = function *range(start, end=undefined, step=1) {
> > > > >   if (end === undefined) [start, end] = [0, start];
> > > > >   if (end === undefined) end = Infinity;
> > > > >   for (let i = 0; i < end; i += step) {
> > > > > yield i;
> > > > >   }
> > > > > };
> > > > > ```
> > > > >
> > > > > On Thu, Nov 3, 2016, 

Re: Ranges

[kdex]

I don't think we should give the Latin alphabet special treatment. This is 
solely about Unicode codepoints.

I'd expect…

- `String.range("AAA", "ZZZ")` to generate ["AAA", "AAB", …, "ABA", … 
"ZZZ"].
- `String.range("", "zzz")` to either throw or be equivalent to 
`String.range("\u", "zzz")`.
- `String.range("z", "A")` to either throw or wrap around at 
"\u{ff}" and therefore include
all codepoints.
- `String.range("A", "z")` to include symbols, too. If you only need 
letters in latin-1, you should
either write a custom latin-1 generator or skip these values 
with a RegExp when iterating
over them. Or just use two ranges, one for A-Z and one for a-z.
- `String.range("A", "π")` to include all characters from "\u0065" (A) 
to "\u03c0" (π).
- `String.range("", "")` to generate ["", "", "", ""] (surrogate 
pairs being respected)

For more complicated cases, it might make more sense to make users pass a 
function to `String.range`
for fine-grained control, or maybe just make users create their own generators.

On Thursday, November 3, 2016 8:54:16 PM CET you wrote:
> Could we just *not* have a `String.range`?
> 
> 1. Needing a list of alphabetically sorted characters is a bit niche, even
> in the Latin alphabet.
> 2. It's ambiguous whether it should include symbols or not. (think:
> `String.range("A", "z")`)
> 3. If it's Unicode-aware, how should it act with, say, `String.range("A",
> "π")`?
> 
> On Thu, Nov 3, 2016, 16:21 Viktor Kronvall 
> wrote:
> 
> > Even more interestingly what would `String.range("","zzz")` produce. From
> > what code point is the range started? Will this throw? Is the empty string
> > included in the iterator?
> > 2016年11月3日(木) 21:18 Viktor Kronvall :
> >
> > Actually, after giving it some more thought for that case there is just
> > that one possibility that makes sense.
> >
> > However, there are more ambiguous cases such as `String.range("AAA",
> > "ZZZ")` (should all letters increase at once or should the rightmost letter
> > be incremented first)
> >
> > Also, how would range handle the arguments in inverted order? Should there
> > be a decreasing range or should it terminate with no elements in the
> > iterator?
> > 2016年11月3日(木) 21:05 kdex :
> >
> > About the code points: `String.range` should also handle surrogate pairs,
> > similar to for..of does it.
> > About `String.range("A", "zzz")`: Do any other possibilities even make
> > sense?
> >
> > On Thursday, November 3, 2016 6:47:04 PM CET Viktor Kronvall wrote:
> > > For `String.range` what would the expected result of
> > > `String.range('A','zzz')` be?
> > >
> > > Is an exhaustive pattern expected?
> > >
> > > `['A','B','C',...'Z','a','b','c',...,'z','AA','AB',...]`
> > > 2016年11月3日(木) 19:21 Michael J. Ryan :
> > >
> > > > If there's a Number.range, if suggest a corresponding String.range for
> > > > character ranges...  Agreed on it being a utility function over me
> > syntax.
> > > >
> > > > On Nov 3, 2016 10:25 AM, "Isiah Meadows" 
> > wrote:
> > > >
> > > > If string ranges are based on character codes, it will (for the Latin
> > > > alphabet, at least, not necessarily for other languages).
> > > >
> > > > I would prefer a function over syntax, though, since it would be more
> > > > easily adopted (polyfill > syntax), and it would fit more idiomatically
> > > > with the rest of the language (which also uses functions for most
> > > > utilities).
> > > >
> > > > Maybe a `Number.range` would work?
> > > >
> > > > ```js
> > > > Number.range = function *range(start, end=undefined, step=1) {
> > > >   if (end === undefined) [start, end] = [0, start];
> > > >   if (end === undefined) end = Infinity;
> > > >   for (let i = 0; i < end; i += step) {
> > > > yield i;
> > > >   }
> > > > };
> > > > ```
> > > >
> > > > On Thu, Nov 3, 2016, 12:56 kdex  wrote:
> > > >
> > > > Agreed. There's no reason why `Array.range` or `[1..10]` couldn't just
> > > > return a generator
> > > > or at least something that extends a generator, though. I wonder if
> > it's
> > > > viable to implement
> > > > something akin to `.length` on ranges, which could be natural numbers
> > or
> > > > `Infinity`.
> > > >
> > > > As for numbers, I don't see any issues. One issue that came up in the
> > > > original thread was
> > > > that string ranges may need a better definition, as ["A".."C"] might
> > not
> > > > necessarily transpile
> > > > to be a generator that yields "A", "B" and "C".
> > > >
> > > > On Thursday, November 3, 2016 4:46:03 PM CET Isiah Meadows wrote:
> > > > > I'll note, just for clarity, that Scala's `1 to 10` is technically
> > just a
> > > > > normal method call equivalent to `(1).to(10)`, with optional
> > parentheses
> > > > > removed.
> > > > >
> > > > > Also, I'd prefer this to be a generator 

Re: Ranges

[Isiah Meadows]

Could we just *not* have a `String.range`?

1. Needing a list of alphabetically sorted characters is a bit niche, even
in the Latin alphabet.
2. It's ambiguous whether it should include symbols or not. (think:
`String.range("A", "z")`)
3. If it's Unicode-aware, how should it act with, say, `String.range("A",
"π")`?

On Thu, Nov 3, 2016, 16:21 Viktor Kronvall 
wrote:

> Even more interestingly what would `String.range("","zzz")` produce. From
> what code point is the range started? Will this throw? Is the empty string
> included in the iterator?
> 2016年11月3日(木) 21:18 Viktor Kronvall :
>
> Actually, after giving it some more thought for that case there is just
> that one possibility that makes sense.
>
> However, there are more ambiguous cases such as `String.range("AAA",
> "ZZZ")` (should all letters increase at once or should the rightmost letter
> be incremented first)
>
> Also, how would range handle the arguments in inverted order? Should there
> be a decreasing range or should it terminate with no elements in the
> iterator?
> 2016年11月3日(木) 21:05 kdex :
>
> About the code points: `String.range` should also handle surrogate pairs,
> similar to for..of does it.
> About `String.range("A", "zzz")`: Do any other possibilities even make
> sense?
>
> On Thursday, November 3, 2016 6:47:04 PM CET Viktor Kronvall wrote:
> > For `String.range` what would the expected result of
> > `String.range('A','zzz')` be?
> >
> > Is an exhaustive pattern expected?
> >
> > `['A','B','C',...'Z','a','b','c',...,'z','AA','AB',...]`
> > 2016年11月3日(木) 19:21 Michael J. Ryan :
> >
> > > If there's a Number.range, if suggest a corresponding String.range for
> > > character ranges...  Agreed on it being a utility function over me
> syntax.
> > >
> > > On Nov 3, 2016 10:25 AM, "Isiah Meadows" 
> wrote:
> > >
> > > If string ranges are based on character codes, it will (for the Latin
> > > alphabet, at least, not necessarily for other languages).
> > >
> > > I would prefer a function over syntax, though, since it would be more
> > > easily adopted (polyfill > syntax), and it would fit more idiomatically
> > > with the rest of the language (which also uses functions for most
> > > utilities).
> > >
> > > Maybe a `Number.range` would work?
> > >
> > > ```js
> > > Number.range = function *range(start, end=undefined, step=1) {
> > >   if (end === undefined) [start, end] = [0, start];
> > >   if (end === undefined) end = Infinity;
> > >   for (let i = 0; i < end; i += step) {
> > > yield i;
> > >   }
> > > };
> > > ```
> > >
> > > On Thu, Nov 3, 2016, 12:56 kdex  wrote:
> > >
> > > Agreed. There's no reason why `Array.range` or `[1..10]` couldn't just
> > > return a generator
> > > or at least something that extends a generator, though. I wonder if
> it's
> > > viable to implement
> > > something akin to `.length` on ranges, which could be natural numbers
> or
> > > `Infinity`.
> > >
> > > As for numbers, I don't see any issues. One issue that came up in the
> > > original thread was
> > > that string ranges may need a better definition, as ["A".."C"] might
> not
> > > necessarily transpile
> > > to be a generator that yields "A", "B" and "C".
> > >
> > > On Thursday, November 3, 2016 4:46:03 PM CET Isiah Meadows wrote:
> > > > I'll note, just for clarity, that Scala's `1 to 10` is technically
> just a
> > > > normal method call equivalent to `(1).to(10)`, with optional
> parentheses
> > > > removed.
> > > >
> > > > Also, I'd prefer this to be a generator instead, so infinite ranges
> are
> > > > also possible, and so it doesn't have to be eager.
> > > >
> > > > On Thu, Nov 3, 2016, 11:52 Hikaru Nakashima <
> oao.hikaru@gmail.com>
> > > > wrote:
> > > >
> > > > > How about this
> > > > >
> > > > > ```
> > > > > for ( i of Array.range(1, 10) ) { ... }
> > > > > // OR
> > > > > for ( i of [1..10] )  { ... }
> > > > > ```
> > > > >
> > > > >
> > > > > ___
> > > > > 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
> > >
> > > ___
> > > 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
> 

Re: Ranges

[Viktor Kronvall]

Even more interestingly what would `String.range("","zzz")` produce. From
what code point is the range started? Will this throw? Is the empty string
included in the iterator?
2016年11月3日(木) 21:18 Viktor Kronvall :

> Actually, after giving it some more thought for that case there is just
> that one possibility that makes sense.
>
> However, there are more ambiguous cases such as `String.range("AAA",
> "ZZZ")` (should all letters increase at once or should the rightmost letter
> be incremented first)
>
> Also, how would range handle the arguments in inverted order? Should there
> be a decreasing range or should it terminate with no elements in the
> iterator?
> 2016年11月3日(木) 21:05 kdex :
>
> About the code points: `String.range` should also handle surrogate pairs,
> similar to for..of does it.
> About `String.range("A", "zzz")`: Do any other possibilities even make
> sense?
>
> On Thursday, November 3, 2016 6:47:04 PM CET Viktor Kronvall wrote:
> > For `String.range` what would the expected result of
> > `String.range('A','zzz')` be?
> >
> > Is an exhaustive pattern expected?
> >
> > `['A','B','C',...'Z','a','b','c',...,'z','AA','AB',...]`
> > 2016年11月3日(木) 19:21 Michael J. Ryan :
> >
> > > If there's a Number.range, if suggest a corresponding String.range for
> > > character ranges...  Agreed on it being a utility function over me
> syntax.
> > >
> > > On Nov 3, 2016 10:25 AM, "Isiah Meadows" 
> wrote:
> > >
> > > If string ranges are based on character codes, it will (for the Latin
> > > alphabet, at least, not necessarily for other languages).
> > >
> > > I would prefer a function over syntax, though, since it would be more
> > > easily adopted (polyfill > syntax), and it would fit more idiomatically
> > > with the rest of the language (which also uses functions for most
> > > utilities).
> > >
> > > Maybe a `Number.range` would work?
> > >
> > > ```js
> > > Number.range = function *range(start, end=undefined, step=1) {
> > >   if (end === undefined) [start, end] = [0, start];
> > >   if (end === undefined) end = Infinity;
> > >   for (let i = 0; i < end; i += step) {
> > > yield i;
> > >   }
> > > };
> > > ```
> > >
> > > On Thu, Nov 3, 2016, 12:56 kdex  wrote:
> > >
> > > Agreed. There's no reason why `Array.range` or `[1..10]` couldn't just
> > > return a generator
> > > or at least something that extends a generator, though. I wonder if
> it's
> > > viable to implement
> > > something akin to `.length` on ranges, which could be natural numbers
> or
> > > `Infinity`.
> > >
> > > As for numbers, I don't see any issues. One issue that came up in the
> > > original thread was
> > > that string ranges may need a better definition, as ["A".."C"] might
> not
> > > necessarily transpile
> > > to be a generator that yields "A", "B" and "C".
> > >
> > > On Thursday, November 3, 2016 4:46:03 PM CET Isiah Meadows wrote:
> > > > I'll note, just for clarity, that Scala's `1 to 10` is technically
> just a
> > > > normal method call equivalent to `(1).to(10)`, with optional
> parentheses
> > > > removed.
> > > >
> > > > Also, I'd prefer this to be a generator instead, so infinite ranges
> are
> > > > also possible, and so it doesn't have to be eager.
> > > >
> > > > On Thu, Nov 3, 2016, 11:52 Hikaru Nakashima <
> oao.hikaru@gmail.com>
> > > > wrote:
> > > >
> > > > > How about this
> > > > >
> > > > > ```
> > > > > for ( i of Array.range(1, 10) ) { ... }
> > > > > // OR
> > > > > for ( i of [1..10] )  { ... }
> > > > > ```
> > > > >
> > > > >
> > > > > ___
> > > > > 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
> > >
> > > ___
> > > 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: Ranges

[Viktor Kronvall]

Actually, after giving it some more thought for that case there is just
that one possibility that makes sense.

However, there are more ambiguous cases such as `String.range("AAA",
"ZZZ")` (should all letters increase at once or should the rightmost letter
be incremented first)

Also, how would range handle the arguments in inverted order? Should there
be a decreasing range or should it terminate with no elements in the
iterator?
2016年11月3日(木) 21:05 kdex :

> About the code points: `String.range` should also handle surrogate pairs,
> similar to for..of does it.
> About `String.range("A", "zzz")`: Do any other possibilities even make
> sense?
>
> On Thursday, November 3, 2016 6:47:04 PM CET Viktor Kronvall wrote:
> > For `String.range` what would the expected result of
> > `String.range('A','zzz')` be?
> >
> > Is an exhaustive pattern expected?
> >
> > `['A','B','C',...'Z','a','b','c',...,'z','AA','AB',...]`
> > 2016年11月3日(木) 19:21 Michael J. Ryan :
> >
> > > If there's a Number.range, if suggest a corresponding String.range for
> > > character ranges...  Agreed on it being a utility function over me
> syntax.
> > >
> > > On Nov 3, 2016 10:25 AM, "Isiah Meadows" 
> wrote:
> > >
> > > If string ranges are based on character codes, it will (for the Latin
> > > alphabet, at least, not necessarily for other languages).
> > >
> > > I would prefer a function over syntax, though, since it would be more
> > > easily adopted (polyfill > syntax), and it would fit more idiomatically
> > > with the rest of the language (which also uses functions for most
> > > utilities).
> > >
> > > Maybe a `Number.range` would work?
> > >
> > > ```js
> > > Number.range = function *range(start, end=undefined, step=1) {
> > >   if (end === undefined) [start, end] = [0, start];
> > >   if (end === undefined) end = Infinity;
> > >   for (let i = 0; i < end; i += step) {
> > > yield i;
> > >   }
> > > };
> > > ```
> > >
> > > On Thu, Nov 3, 2016, 12:56 kdex  wrote:
> > >
> > > Agreed. There's no reason why `Array.range` or `[1..10]` couldn't just
> > > return a generator
> > > or at least something that extends a generator, though. I wonder if
> it's
> > > viable to implement
> > > something akin to `.length` on ranges, which could be natural numbers
> or
> > > `Infinity`.
> > >
> > > As for numbers, I don't see any issues. One issue that came up in the
> > > original thread was
> > > that string ranges may need a better definition, as ["A".."C"] might
> not
> > > necessarily transpile
> > > to be a generator that yields "A", "B" and "C".
> > >
> > > On Thursday, November 3, 2016 4:46:03 PM CET Isiah Meadows wrote:
> > > > I'll note, just for clarity, that Scala's `1 to 10` is technically
> just a
> > > > normal method call equivalent to `(1).to(10)`, with optional
> parentheses
> > > > removed.
> > > >
> > > > Also, I'd prefer this to be a generator instead, so infinite ranges
> are
> > > > also possible, and so it doesn't have to be eager.
> > > >
> > > > On Thu, Nov 3, 2016, 11:52 Hikaru Nakashima <
> oao.hikaru@gmail.com>
> > > > wrote:
> > > >
> > > > > How about this
> > > > >
> > > > > ```
> > > > > for ( i of Array.range(1, 10) ) { ... }
> > > > > // OR
> > > > > for ( i of [1..10] )  { ... }
> > > > > ```
> > > > >
> > > > >
> > > > > ___
> > > > > 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
> > >
> > > ___
> > > 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: Ranges

[kdex]

About the code points: `String.range` should also handle surrogate pairs, 
similar to for..of does it.
About `String.range("A", "zzz")`: Do any other possibilities even make sense?

On Thursday, November 3, 2016 6:47:04 PM CET Viktor Kronvall wrote:
> For `String.range` what would the expected result of
> `String.range('A','zzz')` be?
> 
> Is an exhaustive pattern expected?
> 
> `['A','B','C',...'Z','a','b','c',...,'z','AA','AB',...]`
> 2016年11月3日(木) 19:21 Michael J. Ryan :
> 
> > If there's a Number.range, if suggest a corresponding String.range for
> > character ranges...  Agreed on it being a utility function over me syntax.
> >
> > On Nov 3, 2016 10:25 AM, "Isiah Meadows"  wrote:
> >
> > If string ranges are based on character codes, it will (for the Latin
> > alphabet, at least, not necessarily for other languages).
> >
> > I would prefer a function over syntax, though, since it would be more
> > easily adopted (polyfill > syntax), and it would fit more idiomatically
> > with the rest of the language (which also uses functions for most
> > utilities).
> >
> > Maybe a `Number.range` would work?
> >
> > ```js
> > Number.range = function *range(start, end=undefined, step=1) {
> >   if (end === undefined) [start, end] = [0, start];
> >   if (end === undefined) end = Infinity;
> >   for (let i = 0; i < end; i += step) {
> > yield i;
> >   }
> > };
> > ```
> >
> > On Thu, Nov 3, 2016, 12:56 kdex  wrote:
> >
> > Agreed. There's no reason why `Array.range` or `[1..10]` couldn't just
> > return a generator
> > or at least something that extends a generator, though. I wonder if it's
> > viable to implement
> > something akin to `.length` on ranges, which could be natural numbers or
> > `Infinity`.
> >
> > As for numbers, I don't see any issues. One issue that came up in the
> > original thread was
> > that string ranges may need a better definition, as ["A".."C"] might not
> > necessarily transpile
> > to be a generator that yields "A", "B" and "C".
> >
> > On Thursday, November 3, 2016 4:46:03 PM CET Isiah Meadows wrote:
> > > I'll note, just for clarity, that Scala's `1 to 10` is technically just a
> > > normal method call equivalent to `(1).to(10)`, with optional parentheses
> > > removed.
> > >
> > > Also, I'd prefer this to be a generator instead, so infinite ranges are
> > > also possible, and so it doesn't have to be eager.
> > >
> > > On Thu, Nov 3, 2016, 11:52 Hikaru Nakashima 
> > > wrote:
> > >
> > > > How about this
> > > >
> > > > ```
> > > > for ( i of Array.range(1, 10) ) { ... }
> > > > // OR
> > > > for ( i of [1..10] )  { ... }
> > > > ```
> > > >
> > > >
> > > > ___
> > > > 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
> >
> > ___
> > 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: Proposal of Multithread JavaScript

[Leo Dutra]

I have defined many times, but you guys are in love with workers.

A little look in Java's Runnables would demonstrate de nature and
difference I'm bringing to this thread.

Workers can't even modify DOM directly...

Very different of go routines, Java/Scala threads etc.

Workers require way more control and coding by the nature of their
declaration and messaging. A worker lives and awaits... A thread is run
against a living spawned process and is garbaged after the usage.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Wes Garland]

There is no requirement for a host environment to use any kind of
serialization for worker threads.  It's completely fine to pass messages
which are binary in nature.  In fact, I have  passed C structs as messages
between JavaScript workers.

I don't know why you think this is a fight.  You should understand that you
are proposing a very, very, very significant modification of the ES
standard and you have not yet defined a problem which this work would solve.

Wes

On 3 November 2016 at 14:19, Leo Dutra  wrote:

> Workers need serialization, threads would not.
>
> In Node, lack of threading requires a prior spawn of a bunch of native
> processes and manually build a tasking pool.
>
> Web Workers spawn a specific script (if you respawn the caller you are
> doing dirty job).
>
> Maybe we should fork projects like the one Isiah brought to us and
> headbang compiling it with the lovely gyp.
>
> So much emotion. Much doge work. So delicious.
>
> You could simply spawn a thread in almost the same way we use Node
> streams...
>
> but I won't fight 10 guys alone.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Viktor Kronvall]

For `String.range` what would the expected result of
`String.range('A','zzz')` be?

Is an exhaustive pattern expected?

`['A','B','C',...'Z','a','b','c',...,'z','AA','AB',...]`
2016年11月3日(木) 19:21 Michael J. Ryan :

> If there's a Number.range, if suggest a corresponding String.range for
> character ranges...  Agreed on it being a utility function over me syntax.
>
> On Nov 3, 2016 10:25 AM, "Isiah Meadows"  wrote:
>
> If string ranges are based on character codes, it will (for the Latin
> alphabet, at least, not necessarily for other languages).
>
> I would prefer a function over syntax, though, since it would be more
> easily adopted (polyfill > syntax), and it would fit more idiomatically
> with the rest of the language (which also uses functions for most
> utilities).
>
> Maybe a `Number.range` would work?
>
> ```js
> Number.range = function *range(start, end=undefined, step=1) {
>   if (end === undefined) [start, end] = [0, start];
>   if (end === undefined) end = Infinity;
>   for (let i = 0; i < end; i += step) {
> yield i;
>   }
> };
> ```
>
> On Thu, Nov 3, 2016, 12:56 kdex  wrote:
>
> Agreed. There's no reason why `Array.range` or `[1..10]` couldn't just
> return a generator
> or at least something that extends a generator, though. I wonder if it's
> viable to implement
> something akin to `.length` on ranges, which could be natural numbers or
> `Infinity`.
>
> As for numbers, I don't see any issues. One issue that came up in the
> original thread was
> that string ranges may need a better definition, as ["A".."C"] might not
> necessarily transpile
> to be a generator that yields "A", "B" and "C".
>
> On Thursday, November 3, 2016 4:46:03 PM CET Isiah Meadows wrote:
> > I'll note, just for clarity, that Scala's `1 to 10` is technically just a
> > normal method call equivalent to `(1).to(10)`, with optional parentheses
> > removed.
> >
> > Also, I'd prefer this to be a generator instead, so infinite ranges are
> > also possible, and so it doesn't have to be eager.
> >
> > On Thu, Nov 3, 2016, 11:52 Hikaru Nakashima 
> > wrote:
> >
> > > How about this
> > >
> > > ```
> > > for ( i of Array.range(1, 10) ) { ... }
> > > // OR
> > > for ( i of [1..10] )  { ... }
> > > ```
> > >
> > >
> > > ___
> > > 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
>
> ___
> 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: Proposal of Multithread JavaScript

[Bradley Meck]

Leo you can see https://github.com/nodejs/node/pull/2133 for Workers in
node that use threads instead of processes.

On Thu, Nov 3, 2016 at 1:19 PM, Leo Dutra  wrote:

> Workers need serialization, threads would not.
>
> In Node, lack of threading requires a prior spawn of a bunch of native
> processes and manually build a tasking pool.
>
> Web Workers spawn a specific script (if you respawn the caller you are
> doing dirty job).
>
> Maybe we should fork projects like the one Isiah brought to us and
> headbang compiling it with the lovely gyp.
>
> So much emotion. Much doge work. So delicious.
>
> You could simply spawn a thread in almost the same way we use Node
> streams...
>
> but I won't fight 10 guys alone.
>
> ___
> 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: Ranges

[Michael J. Ryan]

If there's a Number.range, if suggest a corresponding String.range for
character ranges...  Agreed on it being a utility function over me syntax.

On Nov 3, 2016 10:25 AM, "Isiah Meadows"  wrote:

> If string ranges are based on character codes, it will (for the Latin
> alphabet, at least, not necessarily for other languages).
>
> I would prefer a function over syntax, though, since it would be more
> easily adopted (polyfill > syntax), and it would fit more idiomatically
> with the rest of the language (which also uses functions for most
> utilities).
>
> Maybe a `Number.range` would work?
>
> ```js
> Number.range = function *range(start, end=undefined, step=1) {
>   if (end === undefined) [start, end] = [0, start];
>   if (end === undefined) end = Infinity;
>   for (let i = 0; i < end; i += step) {
> yield i;
>   }
> };
> ```
>
> On Thu, Nov 3, 2016, 12:56 kdex  wrote:
>
>> Agreed. There's no reason why `Array.range` or `[1..10]` couldn't just
>> return a generator
>> or at least something that extends a generator, though. I wonder if it's
>> viable to implement
>> something akin to `.length` on ranges, which could be natural numbers or
>> `Infinity`.
>>
>> As for numbers, I don't see any issues. One issue that came up in the
>> original thread was
>> that string ranges may need a better definition, as ["A".."C"] might not
>> necessarily transpile
>> to be a generator that yields "A", "B" and "C".
>>
>> On Thursday, November 3, 2016 4:46:03 PM CET Isiah Meadows wrote:
>> > I'll note, just for clarity, that Scala's `1 to 10` is technically just
>> a
>> > normal method call equivalent to `(1).to(10)`, with optional parentheses
>> > removed.
>> >
>> > Also, I'd prefer this to be a generator instead, so infinite ranges are
>> > also possible, and so it doesn't have to be eager.
>> >
>> > On Thu, Nov 3, 2016, 11:52 Hikaru Nakashima 
>> > wrote:
>> >
>> > > How about this
>> > >
>> > > ```
>> > > for ( i of Array.range(1, 10) ) { ... }
>> > > // OR
>> > > for ( i of [1..10] )  { ... }
>> > > ```
>> > >
>> > >
>> > > ___
>> > > 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Leo Dutra]

Workers need serialization, threads would not.

In Node, lack of threading requires a prior spawn of a bunch of native
processes and manually build a tasking pool.

Web Workers spawn a specific script (if you respawn the caller you are
doing dirty job).

Maybe we should fork projects like the one Isiah brought to us and headbang
compiling it with the lovely gyp.

So much emotion. Much doge work. So delicious.

You could simply spawn a thread in almost the same way we use Node
streams...

but I won't fight 10 guys alone.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Rick Waldron]

Just to make sure this gets attention... Lars Hansen's Shared Memory and
Atomics proposal is at stage 2:

- https://github.com/tc39/ecmascript_sharedmem
-
https://github.com/rwaldron/tc39-notes/blob/master/es7/2016-07/jul-28.md#10iia-shared-memory-and-atomics
-
https://github.com/tc39/ecmascript_sharedmem/blob/master/tc39/sharedmem-jul-2016.pdf


Rick

On Thu, Nov 3, 2016 at 12:34 PM Isiah Meadows 
wrote:

> Chrome/V8 has it behind a flag IIRC. I forget its exact name, but I know
> it exists.
>
> On Thu, Nov 3, 2016, 12:12 J Decker  wrote:
>
> On Thu, Nov 3, 2016 at 9:10 AM, Michał Wadas 
> wrote:
>
> Why you can't solve it with shared memory buffer? Shared - I mean instance
> of *SharedArrayBuffer. *
>
> not in node; in browser ya... where webworkers are threads.  (and not in
> javascript base)
> And while firefox is beginning to look appealing again I'm stuck on chrome
> (native android)
>
>
> On 3 Nov 2016 5:05 p.m., "J Decker"  wrote:
>
>
>
> On Wed, Nov 2, 2016 at 7:44 AM, Michał Wadas 
> wrote:
>
> Actually, is there any problem that can't be easily solved with
> message-passing for high-level structures or low-level shared memory
> buffers?
>
>
> Yes, meshing dynamic geometries that involve a few 20k faces.   If you
> have a thread do the work, the overhead of srealizing the resulting buffers
> will kill any benefit.
>
> But; typed arrays can be shared also.  (they are with C++ addons in node)
>
> The biggest problem with node's lack of threads is they really need
> separate but equal heaps.  I heard that there's a global heap lock... that
> wouldn't be required except when allocating addition space for each heap.
>
>
>
> To the general - stop treating programmers like idiots.  Give us the
> rope.  Let us hang ourselves.
>
>
> ___
> 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
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Isiah Meadows]

If string ranges are based on character codes, it will (for the Latin
alphabet, at least, not necessarily for other languages).

I would prefer a function over syntax, though, since it would be more
easily adopted (polyfill > syntax), and it would fit more idiomatically
with the rest of the language (which also uses functions for most
utilities).

Maybe a `Number.range` would work?

```js
Number.range = function *range(start, end=undefined, step=1) {
  if (end === undefined) [start, end] = [0, start];
  if (end === undefined) end = Infinity;
  for (let i = 0; i < end; i += step) {
yield i;
  }
};
```

On Thu, Nov 3, 2016, 12:56 kdex  wrote:

> Agreed. There's no reason why `Array.range` or `[1..10]` couldn't just
> return a generator
> or at least something that extends a generator, though. I wonder if it's
> viable to implement
> something akin to `.length` on ranges, which could be natural numbers or
> `Infinity`.
>
> As for numbers, I don't see any issues. One issue that came up in the
> original thread was
> that string ranges may need a better definition, as ["A".."C"] might not
> necessarily transpile
> to be a generator that yields "A", "B" and "C".
>
> On Thursday, November 3, 2016 4:46:03 PM CET Isiah Meadows wrote:
> > I'll note, just for clarity, that Scala's `1 to 10` is technically just a
> > normal method call equivalent to `(1).to(10)`, with optional parentheses
> > removed.
> >
> > Also, I'd prefer this to be a generator instead, so infinite ranges are
> > also possible, and so it doesn't have to be eager.
> >
> > On Thu, Nov 3, 2016, 11:52 Hikaru Nakashima 
> > wrote:
> >
> > > How about this
> > >
> > > ```
> > > for ( i of Array.range(1, 10) ) { ... }
> > > // OR
> > > for ( i of [1..10] )  { ... }
> > > ```
> > >
> > >
> > > ___
> > > 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: Ranges

[kdex]

Agreed. There's no reason why `Array.range` or `[1..10]` couldn't just return a 
generator
or at least something that extends a generator, though. I wonder if it's viable 
to implement
something akin to `.length` on ranges, which could be natural numbers or 
`Infinity`.

As for numbers, I don't see any issues. One issue that came up in the original 
thread was
that string ranges may need a better definition, as ["A".."C"] might not 
necessarily transpile
to be a generator that yields "A", "B" and "C".

On Thursday, November 3, 2016 4:46:03 PM CET Isiah Meadows wrote:
> I'll note, just for clarity, that Scala's `1 to 10` is technically just a
> normal method call equivalent to `(1).to(10)`, with optional parentheses
> removed.
> 
> Also, I'd prefer this to be a generator instead, so infinite ranges are
> also possible, and so it doesn't have to be eager.
> 
> On Thu, Nov 3, 2016, 11:52 Hikaru Nakashima 
> wrote:
> 
> > How about this
> >
> > ```
> > for ( i of Array.range(1, 10) ) { ... }
> > // OR
> > for ( i of [1..10] )  { ... }
> > ```
> >
> >
> > ___
> > 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: Ranges

[Isiah Meadows]

I'll note, just for clarity, that Scala's `1 to 10` is technically just a
normal method call equivalent to `(1).to(10)`, with optional parentheses
removed.

Also, I'd prefer this to be a generator instead, so infinite ranges are
also possible, and so it doesn't have to be eager.

On Thu, Nov 3, 2016, 11:52 Hikaru Nakashima 
wrote:

> How about this
>
> ```
> for ( i of Array.range(1, 10) ) { ... }
> // OR
> for ( i of [1..10] )  { ... }
> ```
>
>
> ___
> 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: Proposal of Multithread JavaScript

[Isiah Meadows]

Chrome/V8 has it behind a flag IIRC. I forget its exact name, but I know it
exists.

On Thu, Nov 3, 2016, 12:12 J Decker  wrote:

> On Thu, Nov 3, 2016 at 9:10 AM, Michał Wadas 
> wrote:
>
> Why you can't solve it with shared memory buffer? Shared - I mean instance
> of *SharedArrayBuffer. *
>
> not in node; in browser ya... where webworkers are threads.  (and not in
> javascript base)
> And while firefox is beginning to look appealing again I'm stuck on chrome
> (native android)
>
>
> On 3 Nov 2016 5:05 p.m., "J Decker"  wrote:
>
>
>
> On Wed, Nov 2, 2016 at 7:44 AM, Michał Wadas 
> wrote:
>
> Actually, is there any problem that can't be easily solved with
> message-passing for high-level structures or low-level shared memory
> buffers?
>
>
> Yes, meshing dynamic geometries that involve a few 20k faces.   If you
> have a thread do the work, the overhead of srealizing the resulting buffers
> will kill any benefit.
>
> But; typed arrays can be shared also.  (they are with C++ addons in node)
>
> The biggest problem with node's lack of threads is they really need
> separate but equal heaps.  I heard that there's a global heap lock... that
> wouldn't be required except when allocating addition space for each heap.
>
>
>
> To the general - stop treating programmers like idiots.  Give us the
> rope.  Let us hang ourselves.
>
>
> ___
> 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: Proposal of Multithread JavaScript

[J Decker]

On Thu, Nov 3, 2016 at 9:10 AM, Michał Wadas  wrote:

> Why you can't solve it with shared memory buffer? Shared - I mean instance
> of *SharedArrayBuffer. *
>
> not in node; in browser ya... where webworkers are threads.  (and not in
javascript base)
And while firefox is beginning to look appealing again I'm stuck on chrome
(native android)


> On 3 Nov 2016 5:05 p.m., "J Decker"  wrote:
>
>>
>>
>> On Wed, Nov 2, 2016 at 7:44 AM, Michał Wadas 
>> wrote:
>>
>>> Actually, is there any problem that can't be easily solved with
>>> message-passing for high-level structures or low-level shared memory
>>> buffers?
>>>
>>>
>> Yes, meshing dynamic geometries that involve a few 20k faces.   If you
>> have a thread do the work, the overhead of srealizing the resulting buffers
>> will kill any benefit.
>>
>> But; typed arrays can be shared also.  (they are with C++ addons in node)
>>
>> The biggest problem with node's lack of threads is they really need
>> separate but equal heaps.  I heard that there's a global heap lock... that
>> wouldn't be required except when allocating addition space for each heap.
>>
>>
>>
>> To the general - stop treating programmers like idiots.  Give us the
>> rope.  Let us hang ourselves.
>>
>>
>>> ___
>>> 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: Proposal of Multithread JavaScript

[Michał Wadas]

Why you can't solve it with shared memory buffer? Shared - I mean instance
of *SharedArrayBuffer. *

On 3 Nov 2016 5:05 p.m., "J Decker"  wrote:

>
>
> On Wed, Nov 2, 2016 at 7:44 AM, Michał Wadas 
> wrote:
>
>> Actually, is there any problem that can't be easily solved with
>> message-passing for high-level structures or low-level shared memory
>> buffers?
>>
>>
> Yes, meshing dynamic geometries that involve a few 20k faces.   If you
> have a thread do the work, the overhead of srealizing the resulting buffers
> will kill any benefit.
>
> But; typed arrays can be shared also.  (they are with C++ addons in node)
>
> The biggest problem with node's lack of threads is they really need
> separate but equal heaps.  I heard that there's a global heap lock... that
> wouldn't be required except when allocating addition space for each heap.
>
>
>
> To the general - stop treating programmers like idiots.  Give us the
> rope.  Let us hang ourselves.
>
>
>> ___
>> 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: Proposal of Multithread JavaScript

[J Decker]

On Wed, Nov 2, 2016 at 7:44 AM, Michał Wadas  wrote:

> Actually, is there any problem that can't be easily solved with
> message-passing for high-level structures or low-level shared memory
> buffers?
>
>
Yes, meshing dynamic geometries that involve a few 20k faces.   If you have
a thread do the work, the overhead of srealizing the resulting buffers will
kill any benefit.

But; typed arrays can be shared also.  (they are with C++ addons in node)

The biggest problem with node's lack of threads is they really need
separate but equal heaps.  I heard that there's a global heap lock... that
wouldn't be required except when allocating addition space for each heap.



To the general - stop treating programmers like idiots.  Give us the rope.
Let us hang ourselves.


> ___
> 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: Ranges

[Hikaru Nakashima]

How about this

```
for ( i of Array.range(1, 10) ) { ... }
// OR
for ( i of [1..10] )  { ... }
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Bradley Meck]

> Most of you people barely understand what is being discussed and deny the
ideas presented because you have irrational love for the concepts that have
been already presented and irrational fear of the new concepts. At worst
you rationalize your actions based on the popularity rather than merits.

Ad hominem.

> The green thread proposal such as this would be great. Most Javascript
programs are interactive and have to run concurrently. With bit of work
they wouldn't exclude each other. You could both wait for an event in
thread as well as pass a callback for it.

Agree if done right.

> The problem is that it's too similar to vanilla Javascript.

Similarity is a good thing between language constructs.

> You already have exceptions in form of reject/catch. Did you already have
async/await iterators too?

Unclear why this is relevant.

> Promises are just control flow graphs in disguise. Why would you need two
when you already have proper constructs to represent control flow? These
are complex concepts and excess of them is bad.

JS has been run on event loops, understanding/controlling when you may
yield control back to the event loop is why. Agree that too many concepts
is a bad thing. Unclear how adding greenlets would alleviate this, in
particular things like deferred rendering until your DOM is in a fully
formed state so you don't get FOUC when interacting with *existing* code
that does not expect access/invocation of arguments to yield back to thread.

> You insist you should have safety for non-atomic changes of variables in
a language where the correctness is up to the user in the first place. Why
should we have async/await "safety net" when we don't have types "safety
net"?

Adding more warts because of warts is never a compelling argument.

On Thu, Nov 3, 2016 at 10:08 AM, Henri Tuhola 
wrote:

> Leo Dutra wrote:
> > looks like community is OK with the current state and that's more than
> enough.
>
> This whole mailing list looks like it suffers from a severe case of
> Dunning-Kruger. Most of you people barely understand what is being
> discussed and deny the ideas presented because you have irrational love for
> the concepts that have been already presented and irrational fear of the
> new concepts. At worst you rationalize your actions based on the popularity
> rather than merits.
>
> The green thread proposal such as this would be great. Most Javascript
> programs are interactive and have to run concurrently. With bit of work
> they wouldn't exclude each other. You could both wait for an event in
> thread as well as pass a callback for it.
>
> Async/await has at least two problems.
>
> a) Async routines are infective. The problem here is that it forces you to
> copy/paste otherwise well-behaving programs to make them behave
> concurrently.
>
> For example, you might want to run a parser such that the callback it runs
> will trigger a download and wait for the completion before it proceeds.
>
> With async/await, to do this you have to rewrite portions of the parser
> with async/await keywords to have it run asyncronously. With green threads
> you could just do it.
>
> b) Async/await is a mini-language on top of an existing one. The problem
> is that it's too similar to vanilla Javascript.
>
> You already have exceptions in form of reject/catch. Did you already have
> async/await iterators too?
>
> Promises are just control flow graphs in disguise. Why would you need two
> when you already have proper constructs to represent control flow? These
> are complex concepts and excess of them is bad.
>
>
> The benefits of Async/await over true concurrent model are questionable:
>
> c) Javascript is a dynamic language lacking type annotations prior
> evaluation. With Async/await you insist that it becomes annotated with two
> variations for functions prior evaluation.
>
> You insist you should have safety for non-atomic changes of variables in a
> language where the correctness is up to the user in the first place. Why
> should we have async/await "safety net" when we don't have types "safety
> net"?
>
> -- Henri Tuhola, author of https://leverlanguage.com
>
> ___
> 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: Proposal of Multithread JavaScript

[Wes Garland]

Please do.  I have also done some work in this area.  I have also
implemented asynchronous POSIX signals (fraught with peril) and fork().
Entertaining stuff.

My major problem has always been entrainment of crap from the global
object.  Although it has been a few years since I looked at this (slightly
before ES5 release).

Wes

On 2 November 2016 at 16:28, Isiah Meadows  wrote:

> I'll post it to the list when it's ready, though.
>
> On Wed, Nov 2, 2016, 16:27 Isiah Meadows  wrote:
>
>> I've been working on another idea for parallelism that also leverage
>> modules, but doesn't involve workers. It will enable read-only resource
>> sharing of direct object instances across threads, using realms, a built-in
>> concept of thread ownership, and atomicity for ensuring thread safety. It
>> also allows for blocking calls for individual atomic access.
>>
>> On Wed, Nov 2, 2016, 16:00 Leo Dutra  wrote:
>>
>> We could think in a pool of workers with dynamic code execution or
>> propose, in JS spec, points where multithreading is recommended.
>>
>> Anyway... looks like community is OK with the current state and that's
>> more than enough.
>>
>> Good to see interest, anyways.
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>


-- 
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Henri Tuhola]

Leo Dutra wrote:
> looks like community is OK with the current state and that's more than
enough.

This whole mailing list looks like it suffers from a severe case of
Dunning-Kruger. Most of you people barely understand what is being
discussed and deny the ideas presented because you have irrational love for
the concepts that have been already presented and irrational fear of the
new concepts. At worst you rationalize your actions based on the popularity
rather than merits.

The green thread proposal such as this would be great. Most Javascript
programs are interactive and have to run concurrently. With bit of work
they wouldn't exclude each other. You could both wait for an event in
thread as well as pass a callback for it.

Async/await has at least two problems.

a) Async routines are infective. The problem here is that it forces you to
copy/paste otherwise well-behaving programs to make them behave
concurrently.

For example, you might want to run a parser such that the callback it runs
will trigger a download and wait for the completion before it proceeds.

With async/await, to do this you have to rewrite portions of the parser
with async/await keywords to have it run asyncronously. With green threads
you could just do it.

b) Async/await is a mini-language on top of an existing one. The problem is
that it's too similar to vanilla Javascript.

You already have exceptions in form of reject/catch. Did you already have
async/await iterators too?

Promises are just control flow graphs in disguise. Why would you need two
when you already have proper constructs to represent control flow? These
are complex concepts and excess of them is bad.


The benefits of Async/await over true concurrent model are questionable:

c) Javascript is a dynamic language lacking type annotations prior
evaluation. With Async/await you insist that it becomes annotated with two
variations for functions prior evaluation.

You insist you should have safety for non-atomic changes of variables in a
language where the correctness is up to the user in the first place. Why
should we have async/await "safety net" when we don't have types "safety
net"?

-- Henri Tuhola, author of https://leverlanguage.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Ranges

[kdex]

A few months ago, there was a thread on ESDiscuss [1] where somebody asked for 
native `Range` support,
i.e. numeric ranges, string ranges, etc.

It seems like it didn't receive much attention, so I'd like to bring this up 
for discussion again.

If you were to iterate from X to Y, you would usually use a `for` loop that 
uses a loop variable `i`,
which you would declare with `let`. You can't use `const`, since you'll have to 
increment it, and you
don't want to use `var`, because it makes no sense to make a reference to `i` 
outside of the loop,
unless you were to re-use the loop variable for further loops.

In other words, you're forced to choose a scope where other scopes barely make 
any sense.
Having a for-loop that abstracts over this needless explicitness could help 
make the concept of
iteration more declarative.

Python has `range()` (but no for loops that create ranges) [2], and Scala 
introduced two for-loop syntaxes
that will create ranges for you:

```scala
for (i <- 1 to 10) { … } // 10 inclusive
for (i <- 1 until 10) { … } // 10 exclusive
```

There's a plethora of npm packages that implement ranges, the most popular one 
apparently being `fill-range`
with 7.4 million downloads a month, so it seems that the community would 
appreciate native support a lot.

I've searched through some proposals, but couldn't find anyone currently 
writing a spec for it.
Is there general interest for ranges at TC39? It struck me as odd that the only 
thing I found about them in ES was [1].

[1] https://esdiscuss.org/topic/feature-request-add-range-type-data
[2] https://docs.python.org/3/library/functions.html#func-range
[3] https://www.npmjs.com/package/fill-range
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss