Re: Proposal of Multithread JavaScript

[Isiah Meadows]

And yes, I've been paying attention to safety. What I'm actually going
to be using behind the scenes for the proposal is an event-driven
system to coordinate thread access and having both atomic updates and
synchronized calls by default, and this system will also work with the
event loop as well, with a basic priority system in place.

I'm still working on it, and I plan to have a gist in tandem with
this, so I don't have to have a long, detailed email to start. I just
want to see something a little lighter than just cloning *everything*
(zero copy preferable), and the ability to have high-level
manipulation of shared data without requiring SharedArrayBuffers, a
`malloc` reimplementation, and a boilerplatey abstraction on top of
everything.
-

Isiah Meadows
m...@isiahmeadows.com


On Wed, Nov 2, 2016 at 8:27 PM, Michael J. Ryan  wrote:
> At the module level for a parallel import, etc would be a decent point to
> support parallel execution... But checks would be needed to avoid migration
> at boundaries...
>
> I'm not opposed to parallel execution... But changing the async spec to
> allow unsafe threads is just a really bad idea...  I have also seen many
> bugs in .Net and Java code surrounding bugs and rather not see those types
> of shared/static access in JS.
>
> Having an import worker/parallel with a clean interface could be good...
>
>
> On Nov 2, 2016 1:28 PM, "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
>
>
> ___
> 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: Conditional object properties

[Reinis Ivanovs]

It works in Babel without the parenthesis.

On Wed, Nov 2, 2016 at 5:08 PM, Luke Mitchell  wrote:

> That works, although you have to add parenthesis. It's a nice solution
> but it is still a bit more verbose with the spread, the parenthesis
> and the `: null`.
>
> ```
> let cond = true;
> let obj = {
>   prop1: 'hello',
>   ...(cond ? {prop2: 'world'} : null)};
> // { prop1: 'hello', prop2: 'world' }
>
> cond = false;
> let obj = {
>   prop1: 'hello',
>   ...(cond ? {prop2: 'world'} : null)};
> // { prop1: 'hello' }
> ```
>
> On Wed, Nov 2, 2016 at 2:42 PM, Reinis Ivanovs  wrote:
> > No need for new syntax, you can just do this:
> >
> > ```
> > {...cond ? {prop: value} : null}
> > ```
> >
> > I find it about the same in readability.
> >
> > On Wed, Nov 2, 2016 at 2:18 PM, Luke Mitchell  wrote:
> >>
> >> Hi all,
> >>
> >> I often come across a situation where I wish to extend an object
> >> (usually an argument for an API request) if a particular condition is
> >> satisfied, such as the presence of a function parameter. Currently the
> >> only way to do this is by assigning the object to a variable, checking
> >> the condition using an `if` statement and then extending the object. I
> >> am proposing the inclusion of an operator that allows a property to be
> >> included, subject to a particular condition, inside the object
> >> definition.
> >>
> >> The operator looks like this:
> >>
> >> ```
> >> let obj = {
> >>   cond ? prop: value
> >> };
> >>
> >> ```
> >>
> >> The operator could also be used with a block statement, allowing
> >> multiple properties to be included:
> >>
> >> ```
> >> let obj = {
> >>   cond ? {
> >> prop1: value1,
> >> prop2: value2
> >>   }
> >> };
> >> ```
> >>
> >> I have created a draft proposal and would love to hear any thoughts
> >> you have on the matter. You can find it on my GitHub, at the link
> >> below.
> >>
> >> https://github.com/lukem512/proposal-condition-property-definitions
> >>
> >> Kind regards,
> >> Luke
> >> ___
> >> 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: Conditional object properties

[Bergi]

Luke Mitchell schrieb:

Hi all,

I often come across a situation where I wish to extend an object
(usually an argument for an API request) if a particular condition is
satisfied, such as the presence of a function parameter. Currently the
only way to do this is by assigning the object to a variable, checking
the condition using an `if` statement and then extending the object. I
am proposing the inclusion of an operator that allows a property to be
included, subject to a particular condition, inside the object
definition.


You can already do
```js
let obj = Object.assign({
…
}, cond ? { prop: value } : null);
```
Or depending on your condition, also just `cond && { prop: value }`.

The object spread proposal will achieve the same, without the need for 
any extra operator.


- Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Isiah Meadows]

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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Isiah Meadows]

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
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Leo Dutra]

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

Re: Proposal of Multithread JavaScript

[Wes Garland]

I'm still confused about what problem we are trying to solve here.

I had pthreads-style JS running in JS 1.7 many years ago (
https://github.com/wesgarland/gpsee/tree/master/modules/thread), and after
investing quite a lot of time in making it work, I found that it wasn't
really all that useful in solving any problems I had at the time. Or
since.  Mostly it was written for problems I thought I had, because I was a
C developer trying to bend JS to fit old thought patterns.

Lately, I have been using messaging passing a la DOM workers when I need
parallelization and find it quite useful.

Incidentally, there is no "single thread dogma".  I don't know where you
get this idea.  Running multiple threads of unrelated JS is completely
supported by the existing spec and at least one of the engines.

Finally, Message Passing is not a JS problem either, IMO.  It's a host
environment problem.  This is why, for example, we have DOM workers and not
JS workers.  If you want workers for some other (ie non-browser)
environment, just write it.  It's not hard, and it doesn't need to be part
of the language.

Wes

On 2 November 2016 at 13:32, Florian Bösch  wrote:

> On Wed, Nov 2, 2016 at 6:16 PM, Bradley Meck 
> wrote:
>
>> I'm fine with co-routines, just explicit ones (which we currently have
>> via generators and async functions). Implicit ones make it hard to reason
>> about if a variable needs to place guards prior to performing any action if
>> actions pop the stack in order to do a co-routine pause/resume.
>>
> As I've illustrated, the natural tendency of explicit tagged asynchronous
> code combined with proper software engineering (separation of concerns,
> modularity, reuse, interfaces, encapsulation etc.) will be to infect most
> code with it, until the distinction of "explicit" becomes entirely
> meaningless.
>
> ___
> 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

[Florian Bösch]

On Wed, Nov 2, 2016 at 6:16 PM, Bradley Meck  wrote:

> I'm fine with co-routines, just explicit ones (which we currently have via
> generators and async functions). Implicit ones make it hard to reason about
> if a variable needs to place guards prior to performing any action if
> actions pop the stack in order to do a co-routine pause/resume.
>
As I've illustrated, the natural tendency of explicit tagged asynchronous
code combined with proper software engineering (separation of concerns,
modularity, reuse, interfaces, encapsulation etc.) will be to infect most
code with it, until the distinction of "explicit" becomes entirely
meaningless.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Leo Dutra]

Libuv and browsers use it. But no pool is exposed by API to JS.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Bradley Meck]

> You already have concurrent threads of execution accessing shared mutable
variables with either Promises or async/await. OS level threads are a
particularly nasty variant of multitasking which I'd rather like JS to stay
away from, but I don't see how that'd be an argument against co-routines.

Yes, concurrent and explicitly cooperative. I'm fine with co-routines, just
explicit ones (which we currently have via generators and async functions).
Implicit ones make it hard to reason about if a variable needs to place
guards prior to performing any action if actions pop the stack in order to
do a co-routine pause/resume.

On Wed, Nov 2, 2016 at 12:11 PM, Florian Bösch  wrote:

> On Wed, Nov 2, 2016 at 5:59 PM, Bradley Meck 
> wrote:
>
>> Multiple threads are fine, but the "seamless" shared mutable variables
>> are a no go on my end.
>>
> You already have concurrent threads of execution accessing shared mutable
> variables with either Promises or async/await. OS level threads are a
> particularly nasty variant of multitasking which I'd rather like JS to stay
> away from, but I don't see how that'd be an argument against co-routines.
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Florian Bösch]

On Wed, Nov 2, 2016 at 5:59 PM, Bradley Meck  wrote:

> Multiple threads are fine, but the "seamless" shared mutable variables are
> a no go on my end.
>
You already have concurrent threads of execution accessing shared mutable
variables with either Promises or async/await. OS level threads are a
particularly nasty variant of multitasking which I'd rather like JS to stay
away from, but I don't see how that'd be an argument against co-routines.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Leo Dutra]

Again, async B example is possible and is the proposed.

Workers and SharedArrayBuffers are explicit. I'm proposing a non explicit
thread under existing structures.

The only explicit I'd insert in my proposal are Atomics (for explicit
racing conditions treatments).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Bradley Meck]

Multiple threads are fine, but the "seamless" shared mutable variables are
a no go on my end. As long as concurrent access to any existing
single-thread assuming code is subject to ownership guards it seems fine.
Workers, Atomics, SharedArrayBuffers, Transferables, etc. are places to
look.

On Wed, Nov 2, 2016 at 11:56 AM, Leo Dutra  wrote:

> Nop. I'm saying the opposite.
>
> It will be mutated and it does not matter.
> Imagining that last example I gave, if "B" ran in a thread... Nothing
> would change for the JS developer. "Seamless"... Magik.
>
> The case you are issuing is what I called a change in foundations of JS...
> Making threads declared as in Java... And using volatiles. I hypothesized
> about it... But the effort would be huge and I won't like to see this war.
>
> My proposal is break the single-thread dogma and let async, await,
> promises and components run multithreaded.
>
> Simple, but against the a dogma.
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Bradley Meck]

Everything in this thread? I don't even understand how ownership is not
important if there is concurrent access in JS. All existing JS code was
written under the assumption that the arguments / variables that can be
accessed are not going to be concurrently mutated across threads. *ALL* of
it.

On Wed, Nov 2, 2016 at 11:43 AM, Leo Dutra  wrote:

> Bradley, show me an JS example where ownership would be important and I'll
> call you my guru.
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Leo Dutra]

Nop. I'm saying the opposite.

It will be mutated and it does not matter.
Imagining that last example I gave, if "B" ran in a thread... Nothing would
change for the JS developer. "Seamless"... Magik.

The case you are issuing is what I called a change in foundations of JS...
Making threads declared as in Java... And using volatiles. I hypothesized
about it... But the effort would be huge and I won't like to see this war.

My proposal is break the single-thread dogma and let async, await, promises
and components run multithreaded.

Simple, but against the a dogma.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Proposal of Multithread JavaScript

[doodad-js Admin]

I have used multi-threading in C#/VB.NET where objects are also mutable and I 
have been able to deal with racing conditions without any problem using 
language-provided features and techniques against them.

Currently, to reproduce multi-threading with Node.js, we have to spawn 
processes and use IPC which implies exchange protocols and communication 
channels. That makes more overhead and cause more troubles than real 
multi-threading with shared-objects in memory.

 

Really, I’m waiting too for multi-threading in JS, not just for parallelism, 
but for simplicity and conveniences.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Leo Dutra]

Bradley, show me an JS example where ownership would be important and I'll
call you my guru.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Leo Dutra]

​
​That's what I'm calling seamless multithreading.​

The only change is the spec change of JS being strictly single-threaded.
The proposal is to point aspects where JS can introduce seamless threads
and become more paired with more mature platforms.

Async, Await, I'd add XHR and any other component with a callback, streams
(as it is in Node.js), Promise resolutions and maybe events.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Bradley Meck]

> Not explicit, not important.

Disagree, you cannot convince me otherwise.

> If "b" ran in a thread... what would change for the JS dev?
> Nothing

Not true simply by you needing to make a proposal here.

Also for many contrived examples even with real threads; some cases would
be "unchanged" since they are not racing.



On Wed, Nov 2, 2016 at 11:24 AM, Bradley Meck 
wrote:

> > If "b" ran in a thread... what would change for the JS dev?
> > Nothing
>
> On Wed, Nov 2, 2016 at 11:23 AM, Leo Dutra  wrote:
>
>> > The main thread has all ownership.
>>
>> Not explicit, not important. I changed the outer scope the same way and a
>> will last with the outer scope the same way.
>>
>> If "b" ran in a thread... what would change for the JS dev?
>>
>> Nothing.
>>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Bradley Meck]

> If "b" ran in a thread... what would change for the JS dev?
> Nothing

On Wed, Nov 2, 2016 at 11:23 AM, Leo Dutra  wrote:

> > The main thread has all ownership.
>
> Not explicit, not important. I changed the outer scope the same way and a
> will last with the outer scope the same way.
>
> If "b" ran in a thread... what would change for the JS dev?
>
> Nothing.
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Leo Dutra]

> The main thread has all ownership.

Not explicit, not important. I changed the outer scope the same way and a
will last with the outer scope the same way.

If "b" ran in a thread... what would change for the JS dev?

Nothing.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Bradley Meck]

> Where is your ownership?

The main thread has all ownership.

On Wed, Nov 2, 2016 at 11:14 AM, Leo Dutra  wrote:

> > there are additional checks for scoping to prevent escape from
> isolation that would be needed as well.. not to mention being able to call
> other functions, similarly isolated - Michael
>
> Yes. Expected. And where is the problem? You already have async await
> inside async await. What would change?
> You already share variables and all the outer scope stuff.
>
> There's not a problem with frozen object in workers. But the proposal is
> for multithreading, very different from worker. A worker could be run in a
> process for workers, as it happens in some implementations. A thread is a
> thread. Is directly connected with the process idea originated from POSIX.
> And another facade, worker requires an separate script or dynamic eval.
> This is not maintanance friendly.
>
> Bradley... ownership in JavaScript? Ownership in Rust is applicable...
> every let in Rust, without mutation explicitation, requires ownership.
> JavaScript is the total opposite.
>
> Why would you want ownership today with multithreading if you don't have
> it with single thread?
>
> ​
> ​Ex:
>
> (function outer() {
>   let a = 1;
>
>   let b = async function() {
>  a = 2
>   }
>
>   await b()
>   console.log(a === 2) -> true
>
> })()​
>
> Where is your ownership?
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Leo Dutra]

> there are additional checks for scoping to prevent escape from isolation
that would be needed as well.. not to mention being able to call other
functions, similarly isolated - Michael

Yes. Expected. And where is the problem? You already have async await
inside async await. What would change?
You already share variables and all the outer scope stuff.

There's not a problem with frozen object in workers. But the proposal is
for multithreading, very different from worker. A worker could be run in a
process for workers, as it happens in some implementations. A thread is a
thread. Is directly connected with the process idea originated from POSIX.
And another facade, worker requires an separate script or dynamic eval.
This is not maintanance friendly.

Bradley... ownership in JavaScript? Ownership in Rust is applicable...
every let in Rust, without mutation explicitation, requires ownership.
JavaScript is the total opposite.

Why would you want ownership today with multithreading if you don't have it
with single thread?

​
​Ex:

(function outer() {
  let a = 1;

  let b = async function() {
 a = 2
  }

  await b()
  console.log(a === 2) -> true

})()​

Where is your ownership?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Bradley Meck]

I assert that it cannot be seamless in JS due to the high level of
mutability. Workers seem more viable. Having workers be first class and
using something like ownership in rust might be possible, but shared
mutable heap is not safe without very fine grained and complete transfer of
ownership (this most likely would not work if things
prototypes/getters/setters survive transfer).

On Wed, Nov 2, 2016 at 11:04 AM, Leo Dutra  wrote:

> ​Bradley, understood.
>
> And what in this algorithm would prevent it from being run in another
> thread with this same seamless code?​
>
> ​
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Leo Dutra]

​Bradley, understood.

And what in this algorithm would prevent it from being run in another
thread with this same seamless code?​

​
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Leo Dutra]

Michael... Object.freeze().
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Leo Dutra]

​The problems you are seeing are not in my idea. They are JavaScript
problems I don't want to solve and shall not solve to have what I propose.

The only change for those using async await and promises would be changing
platform version.

Internally, these things would be just moved from Event Loop for a thread
and you would not notice.

I've additionally started a proposition for explicit calls, but that is an
extra and not the core objective.​
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Bradley Meck]

> > XHR is very different since it does not attempt to change state between
threads in a racey fashion.

> Are you sure? It changes DOM all the time, people does it in almost every
callback.

Racey here refers to implicit/preemption. See the following example which
blocks the browser permanently:

```
xhr=new XMLHttpRequest;
xhr.open('GET', 'https://cors-test.appspot.com/test');
xhr.send();
while (xhr.readyState !== 4) {}
```

On Wed, Nov 2, 2016 at 10:57 AM, Leo Dutra  wrote:

> > XHR is very different since it does not attempt to change state between
> threads in a racey fashion.
>
> Are you sure? It changes DOM all the time, people does it in almost every
> callback.
>
> ___
> 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]

> XHR is very different since it does not attempt to change state between
threads in a racey fashion.

Are you sure? It changes DOM all the time, people does it in almost every
callback.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Bradley Meck]

You will need to convince people that their problems with your proposal are
solvable and not dismiss them, not state that your idea has uses. I
completely agree it has uses, but the problems vastly outweigh any use case
in my mind.

On Wed, Nov 2, 2016 at 10:52 AM, Leo Dutra  wrote:

> In JS, if you assign a string to a var containing an object... it will
> become an object.
>
> Michael, I'm sorry to say JavaScript is not "safe". Try
> Java/Haskell/Fortran.
>
> JavaScript is the land of pragmatic algorithms and "for internals and
> abstracted away from you in a safe way".
>
> Workers are cool. I like it.
>
> But for those who knows internals, it is very very expensive. And
> messaging with one worker is easy peasy. Try with 5. That amazing
> onmessages everywhere without a good organization and you will reclaim your
> Visual Studio in no time.
>
> I'm talking about do a single
>
> async rasterizeTheWholeGameStuff() {}
>
> And all the stuff, as a simple async or callback, run inside a green
> thread.
>
> Is that really so much? I don't think so.
> I think all of your statements against it, till now, are not considering
> about being "seamless".
>
> Bösch, I think greenlets is a great example... but I'd take it in a
> second step, thinking about that additionals I put above.
>
> They can't even agree with an existing, full of racing condition and no
> atomicity clojured function body, to be run SEAMLESS in another thread.
>
> Maybe if I create an e-mail like g...@gmail.com or michiok...@gmail.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

[Leo Dutra]

In JS, if you assign a string to a var containing an object... it will
become an object.

Michael, I'm sorry to say JavaScript is not "safe". Try
Java/Haskell/Fortran.

JavaScript is the land of pragmatic algorithms and "for internals and
abstracted away from you in a safe way".

Workers are cool. I like it.

But for those who knows internals, it is very very expensive. And messaging
with one worker is easy peasy. Try with 5. That amazing onmessages
everywhere without a good organization and you will reclaim your Visual
Studio in no time.

I'm talking about do a single

async rasterizeTheWholeGameStuff() {}

And all the stuff, as a simple async or callback, run inside a green thread.

Is that really so much? I don't think so.
I think all of your statements against it, till now, are not considering
about being "seamless".

Bösch, I think greenlets is a great example... but I'd take it in a second
step, thinking about that additionals I put above.

They can't even agree with an existing, full of racing condition and no
atomicity clojured function body, to be run SEAMLESS in another thread.

Maybe if I create an e-mail like g...@gmail.com or michiok...@gmail.com...
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Bradley Meck]

>  XHR does it and is seamless (natively it has to be a thread).

XHR is very different since it does not attempt to change state between
threads in a racey fashion.

On Wed, Nov 2, 2016 at 10:37 AM, Leo Dutra  wrote:

> Bösch... run, change your name and hide in the mountains or they will burn
> all this heresy.
>
> > There is a difference between thread safety and unexpected event
> ordering in a higher level language..  just because you don't think of it
> in the language doesn't mean it isn't there... Also the js environments are
> multi threaded, it's just those threads are for internals and abstracted
> away from you in a safe way.
>
> Sure. The same safe way we can multithread async and await as I said in
> the first statements. That's what I'm calling seamless.
>
> XHR does it and is seamless (natively it has to be a thread).
>
> That's why all the bragging about racing condition applies as much to this
> multithreading as to current callbacks, promises, asyncs and awaits...
>
> If you will fight against it... fight in the foundations. I'm proposing us
> to keep the flow.
>
> Every async would be run in a thread from a pool. Chained or not,
> infectious or not, sharing variables or not... is an internal change I'm
> proposing here.
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Florian Bösch]

There's a fairly good implementation of co-routines called greenlets for
python. It depends on a few basic API calls, these are:

   1. g = greenlet.greenlet(fun) // makes a new greenlet pointing to the
   given function
   2. g.switch(args) // switches to that function
   3. g.switch(value) // once started delivers value inside that functions
   switch call
   4. g.throw(error) // raises an exception into the function
   5. greenlet.getcurrent() // returns the currently running greenlet

With these API primitives, you can implement any flavor of
asynchronous/concurrent scheduler on top if you wish to do so.

On Wed, Nov 2, 2016 at 4:25 PM, Florian Bösch  wrote:

> On Wed, Nov 2, 2016 at 4:13 PM, Bradley Meck 
> wrote:
>
>> Florian, one of the great aspects of generators and async functions in
>> ECMAScript is that they are explicit. It makes understanding where
>> synchronization might need to occur very easy to find. I am unsure what
>> your proposal to prevent infection as you call it would look like if it is
>> explicit.
>>
>
> The theory that await/async are explicit is nice, but flawed, and here's
> why.
>
> If you have a call stack of say A -> B -> C -> D, and you change D to
> async D, you have a problem. C isn't awaiting D, so it needs to do C await
> -> async D, but now C isn't async and B isn't awaiting C, and so forth. So
> you'll end up with an "infection": A await -> async B await -> async C
> await -> async D.
>
> The infection spreads from down the call-stack upwards, and in doing so,
> it spreads sideways as well. If you have say a routine that calls a bunch
> of functions in succession:
>
> A(); B(); C(); D(); and for some reason or other (because your lower level
> framework code became async) all of them now become awaitable as well, you
> end up with await A(); await B(); await C(); await D();
>
> So eventually most calls end up being prefixed by await and most
> functions/methods end up being async, except for low-level code deep down.
>
> It might surprise you that co-routine schedulers work exactly like that.
> Except without all the not needed line-noise. In fact, it could be argued
> that instead of liberally strewing await/async randomly through your code,
> you could simply do a preprocessor that converts every call to an await and
> every closure to an async, that way at least you don't need to type it out
> everytime. Of course you'd also get functionally true co-routines via a
> fairly mindless application of preprocessing.
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Michael J. Ryan]

Sorry for reply...

var a = {};
Thread 1: Object.assign(a, {...});
Thread 2: Object.assign(a, {...});

So many places to blow up internally it isn't funny... Also, as I said,
even where threading is first class with locking, there are really weird
bugs when people who don't intimately understand things write code...

Having a clear worker pattern is safer...  Adding internalized immutables
to improve message passing would be nice, as would an rpc to promise
interface...

Real threads however is a truly bad idea in JS...

On Nov 2, 2016 8:31 AM, "Michael J. Ryan"  wrote:

There is a difference between thread safety and unexpected event ordering
in a higher level language..  just because you don't think of it in the
language doesn't mean it isn't there... Also the js environments are multi
threaded, it's just those threads are for internals and abstracted away
from you in a safe way.

On Nov 2, 2016 8:26 AM, "Leo Dutra"  wrote:

> Is not a matter of being faster. Is a matter of using machine potential
> and using better internal instructions.
> JavaScript sits over libuv and engines with multithreading without using
> multithreading.
>
> And about being faster, any serious language has a simple feature like
> threads and Visual Basic should not emerge even in Microsoft specs
> discussions. What comes next? PHP?
>
> I still don't understand why you talk so much about racing conditions in a
> language which one of the main aspects is loose clojuring and racing
> condition.
>
> Who cares about thread-safety if it were never expected and if it all can
> be seamless. And where it would not be explicit?
>
>
>
>
> ___
> 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]

Bösch... run, change your name and hide in the mountains or they will burn
all this heresy.

> There is a difference between thread safety and unexpected event ordering
in a higher level language..  just because you don't think of it in the
language doesn't mean it isn't there... Also the js environments are multi
threaded, it's just those threads are for internals and abstracted away
from you in a safe way.

Sure. The same safe way we can multithread async and await as I said in the
first statements. That's what I'm calling seamless.

XHR does it and is seamless (natively it has to be a thread).

That's why all the bragging about racing condition applies as much to this
multithreading as to current callbacks, promises, asyncs and awaits...

If you will fight against it... fight in the foundations. I'm proposing us
to keep the flow.

Every async would be run in a thread from a pool. Chained or not,
infectious or not, sharing variables or not... is an internal change I'm
proposing here.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Michael J. Ryan]

There is a difference between thread safety and unexpected event ordering
in a higher level language..  just because you don't think of it in the
language doesn't mean it isn't there... Also the js environments are multi
threaded, it's just those threads are for internals and abstracted away
from you in a safe way.

On Nov 2, 2016 8:26 AM, "Leo Dutra"  wrote:

> Is not a matter of being faster. Is a matter of using machine potential
> and using better internal instructions.
> JavaScript sits over libuv and engines with multithreading without using
> multithreading.
>
> And about being faster, any serious language has a simple feature like
> threads and Visual Basic should not emerge even in Microsoft specs
> discussions. What comes next? PHP?
>
> I still don't understand why you talk so much about racing conditions in a
> language which one of the main aspects is loose clojuring and racing
> condition.
>
> Who cares about thread-safety if it were never expected and if it all can
> be seamless. And where it would not be explicit?
>
>
>
>
> ___
> 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]

Is not a matter of being faster. Is a matter of using machine potential and
using better internal instructions.
JavaScript sits over libuv and engines with multithreading without using
multithreading.

And about being faster, any serious language has a simple feature like
threads and Visual Basic should not emerge even in Microsoft specs
discussions. What comes next? PHP?

I still don't understand why you talk so much about racing conditions in a
language which one of the main aspects is loose clojuring and racing
condition.

Who cares about thread-safety if it were never expected and if it all can
be seamless. And where it would not be explicit?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Florian Bösch]

On Wed, Nov 2, 2016 at 4:13 PM, Bradley Meck  wrote:

> Florian, one of the great aspects of generators and async functions in
> ECMAScript is that they are explicit. It makes understanding where
> synchronization might need to occur very easy to find. I am unsure what
> your proposal to prevent infection as you call it would look like if it is
> explicit.
>

The theory that await/async are explicit is nice, but flawed, and here's
why.

If you have a call stack of say A -> B -> C -> D, and you change D to async
D, you have a problem. C isn't awaiting D, so it needs to do C await ->
async D, but now C isn't async and B isn't awaiting C, and so forth. So
you'll end up with an "infection": A await -> async B await -> async C
await -> async D.

The infection spreads from down the call-stack upwards, and in doing so, it
spreads sideways as well. If you have say a routine that calls a bunch of
functions in succession:

A(); B(); C(); D(); and for some reason or other (because your lower level
framework code became async) all of them now become awaitable as well, you
end up with await A(); await B(); await C(); await D();

So eventually most calls end up being prefixed by await and most
functions/methods end up being async, except for low-level code deep down.

It might surprise you that co-routine schedulers work exactly like that.
Except without all the not needed line-noise. In fact, it could be argued
that instead of liberally strewing await/async randomly through your code,
you could simply do a preprocessor that converts every call to an await and
every closure to an async, that way at least you don't need to type it out
everytime. Of course you'd also get functionally true co-routines via a
fairly mindless application of preprocessing.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Michael J. Ryan]

Given how many bugs I've dealt with involving race conditions in .Net, I
would really rather have a solid worker pattern over any internal threading
inside the main event loop in js as this thread has proposed...

Adding an rpc-like promise callback in addition to, or over message passing
would be far safer...

Internal threading may be "a solved problem" but it creates so many new
ones with really weird bugs to go with them.

On Nov 2, 2016 8:03 AM, "Bradley Meck"  wrote:

>
> > As I said... JS has mutable objects by default. The memory space SHALL
> be the same.
>
> > What is not being covered? Let it come to the surface.
>
> As stated, that single threaded access to objects and shared memory
> multi-threaded access are very different.
>
> On Wed, Nov 2, 2016 at 9:56 AM, Leo Dutra  wrote:
>
>> Message passing between two objects is a Law of Nature, broad and
>> powerful.
>> But there's more than just workers and process spawn in life.
>>
>> As I said... JS has mutable objects by default. The memory space SHALL be
>> the same.
>>
>> Atomic could handle the racing when needed and a Mutex for locking.
>>
>> What is not being covered? Let it come to the surface.
>>
>
>
> ___
> 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

[Florian Bösch]

What I meant to illustrate is that concurrency always leads to race
conditions, and that neither promises nor async/await are free of them, and
so it's silly to argue against co-routines on that basis, because of all
the continuation mechanisms, they're the most convenient to use with the
least drawbacks (no infectiveness).

On Wed, Nov 2, 2016 at 4:08 PM, Leo Dutra  wrote:

> Bösch, this is the legacy of callbacks.
>
> ECMA does a great job with specs, but JS does every step to solve the last
> step.
>
> Callback became a promise for modularity. Promise is hidden in async await
> for simplicity. Common constructs, but in JS they came in being adapted for
> JS world.
>
> As I said, immutability is not strong in JS as it is not a PURE functional
> programming language.
>
> Weird or not, this led us to the possibility of multithreading with total
> share and mutability.
>
> If we wanna multithread in here, we have to respect all the JavaScript
> legacy. And the JavaScript legacy hurts Java/C#/whatever feelings cause IT
> IS DIFFERENT.
>
> As said in my first argumentation, we have race condition problems and
> total share of scope and none died because of it. Multithread can be used
> to run these callbacks, functions and promises seamlessly and if we want it
> different... that's a huge bad conversation about foundations of JavaScript
> and a total change that would wreck the JS world and let us to anything
> that is not JS.
>
> We have to decide if we stick with scope sharing and mutability or look
> for another language. JS is what it is.
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Bradley Meck]

Note: this is not an implementation issue, this is a shared access
introducing bugs issue.

On Wed, Nov 2, 2016 at 10:10 AM, Leo Dutra  wrote:

> ​Bradley, JIT can take care of it. If too hard... "volatile" reserved word
> is around since the early 00's.​
>
>
>
> *Leo Dutra, **on **Facebook  **and 
> LinkedIn
> *
>
> 2016-11-02 13:03 GMT-02:00 Bradley Meck :
>
>>
>> > As I said... JS has mutable objects by default. The memory space SHALL
>> be the same.
>>
>> > What is not being covered? Let it come to the surface.
>>
>> As stated, that single threaded access to objects and shared memory
>> multi-threaded access are very different.
>>
>> On Wed, Nov 2, 2016 at 9:56 AM, Leo Dutra  wrote:
>>
>>> Message passing between two objects is a Law of Nature, broad and
>>> powerful.
>>> But there's more than just workers and process spawn in life.
>>>
>>> As I said... JS has mutable objects by default. The memory space SHALL
>>> be the same.
>>>
>>> Atomic could handle the racing when needed and a Mutex for locking.
>>>
>>> What is not being covered? Let it come to the surface.
>>>
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Michał Wadas]

Why do you need it to be faster? Actual processing of hundreds items is
fast enough on PC (under 16ms) and very likely to be fast enough on mobile.
If you are writing game probably the better choice would be to go with raw
numbers and/or compiled language than deal with performance hit and racing
conditions in whole codebase. Because libraries are not guaranteed to be
thread-safe when accessed. Even basic language spec isn't designed to be
thread-safe.

Multithreading in manage language with virtual machine requires constant
guards. It's not a C - changing object shape in middle of another operation
is likely to cause a trouble. Even simple `foo.bar = 42` requires following
steps for [[Set]] operations and these steps are not thread-safe.

On Wed, Nov 2, 2016 at 3:46 PM, Leo Dutra  wrote:

> This is not only easier, this is faster.
>
> We have a single memory allocation and all the threads share it.
> Considering your case:
>
> let a = {};
>
> async alpha() { a.text += 'hello' }
> async beta() { a.text + ' world' }
>
> parallel.all( a, b ) // or thread.parallel( a, b )
> .then(x -> console.log(x))
>
> Will output ' worldhello' or 'hello world' like any multithread platform
> will.
>
>
>
> *Leo Dutra, **on **Facebook  **and 
> LinkedIn
> *
>
> 2016-11-02 12:39 GMT-02:00 Leo Dutra :
>
>> If it is accepted, yes... Atomics should take care of racing.
>>
>> We have a lighter context than most functional languages with this
>> proposal: we reassure JavaScript memory is totally mutable (against
>> Erlang/Rust/Haskell).
>>
>> This keeps the job easier. I was thinking in the worst possibility and we
>> have the easier.
>>
>> Lock, immutability and not shared mutation are the special cases.
>> For these cases, Atomic and Mutex constructs will fit.
>>
>>
>> *Leo Dutra, **on **Facebook  **and 
>> LinkedIn
>> *
>>
>> 2016-11-02 12:27 GMT-02:00 Bradley Meck :
>>
>>> Consider:
>>>
>>> ```
>>> let a = {};
>>>
>>> alpha: parallel {
>>>   a.text = 'hello';
>>> }
>>> beta: parallel {
>>>   a.text += ' world';
>>> }
>>> console.log(a);
>>> ```
>>>
>>> This has racing:
>>> * around `a.text` between `alpha:` and `beta:`.
>>> * around `console.log` since `a` could be 1 of 3 values depending on how
>>> threads are scheduled.
>>>
>>> I am stating that such racing/shared mutation should be prevented.
>>> Workers do this by message passing and ownership of transferable data.
>>> There could be other mechanics for synchronization, but I don't see a
>>> simplistic solution. Things like having a read-only view of data partially
>>> helps, but atomics are most likely the proper way to do this if you don't
>>> want message passing and ownership semantics.
>>>
>>> On Wed, Nov 2, 2016 at 9:09 AM, Leo Dutra  wrote:
>>>
 ​There's nothing about threading that is not problem with Event loop.
 I'd say there's even less problems.

 The proposal is a seamless behaviour, equals to what we have now.

 Message passing is not a problem of JS developer in the case, but a
 V8/WhateverMonkey problem.

 Changing a value inside a multithread async MUST behave in the same way
 of a change inside a single threaded async. The same way, non-referenced
 variables SHALL NOT be scoped in the thread. This is not Java with
 volatiles. This is the plain old JS with clojures, openess and loose bare
 metal control.

 Thread interruption is a bad practice anyway. And we could have a Mutex
 class for the specific case or another idea.

 Workers are evented and started, not pooled and easy to use.
 ​


 *Leo Dutra, **on **Facebook  **and 
 LinkedIn
 *

 2016-11-02 11:57 GMT-02:00 Bradley Meck :

> We need to be careful about this, I would never condone adding
> threading that could share variables that were not intended to be
> multi-threaded, as such variable access outside of your `parallelize`
> construct/syntax would need to be message passing when talking to 
> something
> that is not already written as a parallel structure. A notable thing here
> is that Shared Memory and Atomics that are in ECMA Stage 2 :
> https://github.com/tc39/ecmascript_sharedmem which would probably
> need to land prior to me condoning any shared mutable state.
>
> Historically, all JS implementations are based upon a job queueing
> system described by the Event Loop. This is very different from 
> parallelism
> which could have shared mutable state. All code is guaranteed to have
> exclusive access to variables in scope until it finishes running, and that
> the content of those variables will 

Re: Proposal of Multithread JavaScript

[Bradley Meck]

Florian, one of the great aspects of generators and async functions in
ECMAScript is that they are explicit. It makes understanding where
synchronization might need to occur very easy to find. I am unsure what
your proposal to prevent infection as you call it would look like if it is
explicit.

On Wed, Nov 2, 2016 at 10:11 AM, Florian Bösch  wrote:

> What I meant to illustrate is that concurrency always leads to race
> conditions, and that neither promises nor async/await are free of them, and
> so it's silly to argue against co-routines on that basis, because of all
> the continuation mechanisms, they're the most convenient to use with the
> least drawbacks (no infectiveness).
>
> On Wed, Nov 2, 2016 at 4:08 PM, Leo Dutra  wrote:
>
>> Bösch, this is the legacy of callbacks.
>>
>> ECMA does a great job with specs, but JS does every step to solve the
>> last step.
>>
>> Callback became a promise for modularity. Promise is hidden in async
>> await for simplicity. Common constructs, but in JS they came in being
>> adapted for JS world.
>>
>> As I said, immutability is not strong in JS as it is not a PURE
>> functional programming language.
>>
>> Weird or not, this led us to the possibility of multithreading with total
>> share and mutability.
>>
>> If we wanna multithread in here, we have to respect all the JavaScript
>> legacy. And the JavaScript legacy hurts Java/C#/whatever feelings cause IT
>> IS DIFFERENT.
>>
>> As said in my first argumentation, we have race condition problems and
>> total share of scope and none died because of it. Multithread can be used
>> to run these callbacks, functions and promises seamlessly and if we want it
>> different... that's a huge bad conversation about foundations of JavaScript
>> and a total change that would wreck the JS world and let us to anything
>> that is not JS.
>>
>> We have to decide if we stick with scope sharing and mutability or look
>> for another language. JS is what it is.
>>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Leo Dutra]

​Bradley, JIT can take care of it. If too hard... "volatile" reserved word
is around since the early 00's.​



*Leo Dutra, **on **Facebook 
**and LinkedIn
*

2016-11-02 13:03 GMT-02:00 Bradley Meck :

>
> > As I said... JS has mutable objects by default. The memory space SHALL
> be the same.
>
> > What is not being covered? Let it come to the surface.
>
> As stated, that single threaded access to objects and shared memory
> multi-threaded access are very different.
>
> On Wed, Nov 2, 2016 at 9:56 AM, Leo Dutra  wrote:
>
>> Message passing between two objects is a Law of Nature, broad and
>> powerful.
>> But there's more than just workers and process spawn in life.
>>
>> As I said... JS has mutable objects by default. The memory space SHALL be
>> the same.
>>
>> Atomic could handle the racing when needed and a Mutex for locking.
>>
>> What is not being covered? Let it come to the surface.
>>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Leo Dutra]

Bösch, this is the legacy of callbacks.

ECMA does a great job with specs, but JS does every step to solve the last
step.

Callback became a promise for modularity. Promise is hidden in async await
for simplicity. Common constructs, but in JS they came in being adapted for
JS world.

As I said, immutability is not strong in JS as it is not a PURE functional
programming language.

Weird or not, this led us to the possibility of multithreading with total
share and mutability.

If we wanna multithread in here, we have to respect all the JavaScript
legacy. And the JavaScript legacy hurts Java/C#/whatever feelings cause IT
IS DIFFERENT.

As said in my first argumentation, we have race condition problems and
total share of scope and none died because of it. Multithread can be used
to run these callbacks, functions and promises seamlessly and if we want it
different... that's a huge bad conversation about foundations of JavaScript
and a total change that would wreck the JS world and let us to anything
that is not JS.

We have to decide if we stick with scope sharing and mutability or look for
another language. JS is what it is.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Conditional object properties

[Luke Mitchell]

That works, although you have to add parenthesis. It's a nice solution
but it is still a bit more verbose with the spread, the parenthesis
and the `: null`.

```
let cond = true;
let obj = {
  prop1: 'hello',
  ...(cond ? {prop2: 'world'} : null)};
// { prop1: 'hello', prop2: 'world' }

cond = false;
let obj = {
  prop1: 'hello',
  ...(cond ? {prop2: 'world'} : null)};
// { prop1: 'hello' }
```

On Wed, Nov 2, 2016 at 2:42 PM, Reinis Ivanovs  wrote:
> No need for new syntax, you can just do this:
>
> ```
> {...cond ? {prop: value} : null}
> ```
>
> I find it about the same in readability.
>
> On Wed, Nov 2, 2016 at 2:18 PM, Luke Mitchell  wrote:
>>
>> Hi all,
>>
>> I often come across a situation where I wish to extend an object
>> (usually an argument for an API request) if a particular condition is
>> satisfied, such as the presence of a function parameter. Currently the
>> only way to do this is by assigning the object to a variable, checking
>> the condition using an `if` statement and then extending the object. I
>> am proposing the inclusion of an operator that allows a property to be
>> included, subject to a particular condition, inside the object
>> definition.
>>
>> The operator looks like this:
>>
>> ```
>> let obj = {
>>   cond ? prop: value
>> };
>>
>> ```
>>
>> The operator could also be used with a block statement, allowing
>> multiple properties to be included:
>>
>> ```
>> let obj = {
>>   cond ? {
>> prop1: value1,
>> prop2: value2
>>   }
>> };
>> ```
>>
>> I have created a draft proposal and would love to hear any thoughts
>> you have on the matter. You can find it on my GitHub, at the link
>> below.
>>
>> https://github.com/lukem512/proposal-condition-property-definitions
>>
>> Kind regards,
>> Luke
>> ___
>> 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]

Message passing between two objects is a Law of Nature, broad and powerful.
But there's more than just workers and process spawn in life.

As I said... JS has mutable objects by default. The memory space SHALL be
the same.

Atomic could handle the racing when needed and a Mutex for locking.

What is not being covered? Let it come to the surface.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Florian Bösch]

I'd like to quickly point out that Promises, async/await are actually
implementations of co-routines. Unlike true co-routines however they're
infective (once something down the call stack becomes a promise or an
async, it infects upwards). They have none of the conveniences of actual
co-routines (non infective, control flow/structural semantic is preserved),
while sharing all of the drawbacks of any other cooperative multitasking
scheme (data corruption).

Racing in promises:

xhr().then(function(){a.text = 'foo'})
xhr().then(function(){a.text += 'bar'})


Racing in async/await:


async function foo(){ a.text = await xhr(); }
async function bar(){ a.text += await xhr(); }
await* [foo(), bar()]


Racing with cooperative multitasking (assuming greenlet semantics and a
trampoline I/O scheduler):

scheduler.spawn(function(){
  a.text = xhr();
});
scheduler.spawn(function(){
  a.text += xhr();
});


None of these examples is really representative of what people would
actually do, which is:

Promises:

xhr()
  .then(function(){
a.text = 'foo';
return xhr();
  })
  .then(function(){
a.text += 'bar';
  })


async/await

a.text = await xhr();
a.text += await xhr();


Co-routines:

a.text = xhr();
a.text += xhr();


However we can see how actual co-routines would have a marked advantage in
simplicity and conciseness.

All forms of cooperative multitasking would eventually have to evolve a
barrier mechanism to deal with data corruption. Promises are severely
handycapped in that regard as they cannot create barriers at all.
Async/await barriers are conceivable, but awkward. Co-routine barriers are
relatively straightforward to implement if you control your scheduler
implementaiton.

It should be noted that controlling what kind of scheduler you use would be
kinda important, which is one convenient aspect of co-routines, they can
easily implement a custom one fit for your needs.

On Wed, Nov 2, 2016 at 3:27 PM, Bradley Meck  wrote:

> Consider:
>
> ```
> let a = {};
>
> alpha: parallel {
>   a.text = 'hello';
> }
> beta: parallel {
>   a.text += ' world';
> }
> console.log(a);
> ```
>
> This has racing:
> * around `a.text` between `alpha:` and `beta:`.
> * around `console.log` since `a` could be 1 of 3 values depending on how
> threads are scheduled.
>
> I am stating that such racing/shared mutation should be prevented. Workers
> do this by message passing and ownership of transferable data. There could
> be other mechanics for synchronization, but I don't see a simplistic
> solution. Things like having a read-only view of data partially helps, but
> atomics are most likely the proper way to do this if you don't want message
> passing and ownership semantics.
>
> On Wed, Nov 2, 2016 at 9:09 AM, Leo Dutra  wrote:
>
>> ​There's nothing about threading that is not problem with Event loop.
>> I'd say there's even less problems.
>>
>> The proposal is a seamless behaviour, equals to what we have now.
>>
>> Message passing is not a problem of JS developer in the case, but a
>> V8/WhateverMonkey problem.
>>
>> Changing a value inside a multithread async MUST behave in the same way
>> of a change inside a single threaded async. The same way, non-referenced
>> variables SHALL NOT be scoped in the thread. This is not Java with
>> volatiles. This is the plain old JS with clojures, openess and loose bare
>> metal control.
>>
>> Thread interruption is a bad practice anyway. And we could have a Mutex
>> class for the specific case or another idea.
>>
>> Workers are evented and started, not pooled and easy to use.
>> ​
>>
>>
>> *Leo Dutra, **on **Facebook  **and 
>> LinkedIn
>> *
>>
>> 2016-11-02 11:57 GMT-02:00 Bradley Meck :
>>
>>> We need to be careful about this, I would never condone adding threading
>>> that could share variables that were not intended to be multi-threaded, as
>>> such variable access outside of your `parallelize` construct/syntax would
>>> need to be message passing when talking to something that is not already
>>> written as a parallel structure. A notable thing here is that Shared Memory
>>> and Atomics that are in ECMA Stage 2 : https://github.com/tc39/ecma
>>> script_sharedmem which would probably need to land prior to me
>>> condoning any shared mutable state.
>>>
>>> Historically, all JS implementations are based upon a job queueing
>>> system described by the Event Loop. This is very different from parallelism
>>> which could have shared mutable state. All code is guaranteed to have
>>> exclusive access to variables in scope until it finishes running, and that
>>> the content of those variables will not change from preemption (there are
>>> cases where this is not true in the browser with a live DOM). There are
>>> alternative discussion recently on Workers :
>>> https://esdiscuss.org/topic/standardize-es-worker . I might look there
>>> first.
>>>
>>> 

Re: Proposal of Multithread JavaScript

[Michał Wadas]

Actually, is there any problem that can't be easily solved with
message-passing for high-level structures or low-level shared memory
buffers?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Leo Dutra]

Sorry...

let a = {};

async alpha() { a.text += 'hello' }
async beta() { a.text + ' world' }

parallel.all( a, b ) // or thread.parallel( a, b )
.then(() -> console.log(a.text))


*Leo Dutra, **on **Facebook 
**and LinkedIn
*

2016-11-02 12:46 GMT-02:00 Leo Dutra :

> This is not only easier, this is faster.
>
> We have a single memory allocation and all the threads share it.
> Considering your case:
>
> let a = {};
>
> async alpha() { a.text += 'hello' }
> async beta() { a.text + ' world' }
>
> parallel.all( a, b ) // or thread.parallel( a, b )
> .then(x -> console.log(x))
>
> Will output ' worldhello' or 'hello world' like any multithread platform
> will.
>
>
>
> *Leo Dutra, **on **Facebook  **and 
> LinkedIn
> *
>
> 2016-11-02 12:39 GMT-02:00 Leo Dutra :
>
>> If it is accepted, yes... Atomics should take care of racing.
>>
>> We have a lighter context than most functional languages with this
>> proposal: we reassure JavaScript memory is totally mutable (against
>> Erlang/Rust/Haskell).
>>
>> This keeps the job easier. I was thinking in the worst possibility and we
>> have the easier.
>>
>> Lock, immutability and not shared mutation are the special cases.
>> For these cases, Atomic and Mutex constructs will fit.
>>
>>
>> *Leo Dutra, **on **Facebook  **and 
>> LinkedIn
>> *
>>
>> 2016-11-02 12:27 GMT-02:00 Bradley Meck :
>>
>>> Consider:
>>>
>>> ```
>>> let a = {};
>>>
>>> alpha: parallel {
>>>   a.text = 'hello';
>>> }
>>> beta: parallel {
>>>   a.text += ' world';
>>> }
>>> console.log(a);
>>> ```
>>>
>>> This has racing:
>>> * around `a.text` between `alpha:` and `beta:`.
>>> * around `console.log` since `a` could be 1 of 3 values depending on how
>>> threads are scheduled.
>>>
>>> I am stating that such racing/shared mutation should be prevented.
>>> Workers do this by message passing and ownership of transferable data.
>>> There could be other mechanics for synchronization, but I don't see a
>>> simplistic solution. Things like having a read-only view of data partially
>>> helps, but atomics are most likely the proper way to do this if you don't
>>> want message passing and ownership semantics.
>>>
>>> On Wed, Nov 2, 2016 at 9:09 AM, Leo Dutra  wrote:
>>>
 ​There's nothing about threading that is not problem with Event loop.
 I'd say there's even less problems.

 The proposal is a seamless behaviour, equals to what we have now.

 Message passing is not a problem of JS developer in the case, but a
 V8/WhateverMonkey problem.

 Changing a value inside a multithread async MUST behave in the same way
 of a change inside a single threaded async. The same way, non-referenced
 variables SHALL NOT be scoped in the thread. This is not Java with
 volatiles. This is the plain old JS with clojures, openess and loose bare
 metal control.

 Thread interruption is a bad practice anyway. And we could have a Mutex
 class for the specific case or another idea.

 Workers are evented and started, not pooled and easy to use.
 ​


 *Leo Dutra, **on **Facebook  **and 
 LinkedIn
 *

 2016-11-02 11:57 GMT-02:00 Bradley Meck :

> We need to be careful about this, I would never condone adding
> threading that could share variables that were not intended to be
> multi-threaded, as such variable access outside of your `parallelize`
> construct/syntax would need to be message passing when talking to 
> something
> that is not already written as a parallel structure. A notable thing here
> is that Shared Memory and Atomics that are in ECMA Stage 2 :
> https://github.com/tc39/ecmascript_sharedmem which would probably
> need to land prior to me condoning any shared mutable state.
>
> Historically, all JS implementations are based upon a job queueing
> system described by the Event Loop. This is very different from 
> parallelism
> which could have shared mutable state. All code is guaranteed to have
> exclusive access to variables in scope until it finishes running, and that
> the content of those variables will not change from preemption (there are
> cases where this is not true in the browser with a live DOM). There are
> alternative discussion recently on Workers :
> https://esdiscuss.org/topic/standardize-es-worker . I might look
> there first.
>
> In particular, I would suggest taking a look at problems of
> synchronization, locking, and preemption breaking existing code a bit
> rather than just stating that green threads are 

Re: Proposal of Multithread JavaScript

[Leo Dutra]

This is not only easier, this is faster.

We have a single memory allocation and all the threads share it.
Considering your case:

let a = {};

async alpha() { a.text += 'hello' }
async beta() { a.text + ' world' }

parallel.all( a, b ) // or thread.parallel( a, b )
.then(x -> console.log(x))

Will output ' worldhello' or 'hello world' like any multithread platform
will.



*Leo Dutra, **on **Facebook 
**and LinkedIn
*

2016-11-02 12:39 GMT-02:00 Leo Dutra :

> If it is accepted, yes... Atomics should take care of racing.
>
> We have a lighter context than most functional languages with this
> proposal: we reassure JavaScript memory is totally mutable (against
> Erlang/Rust/Haskell).
>
> This keeps the job easier. I was thinking in the worst possibility and we
> have the easier.
>
> Lock, immutability and not shared mutation are the special cases.
> For these cases, Atomic and Mutex constructs will fit.
>
>
> *Leo Dutra, **on **Facebook  **and 
> LinkedIn
> *
>
> 2016-11-02 12:27 GMT-02:00 Bradley Meck :
>
>> Consider:
>>
>> ```
>> let a = {};
>>
>> alpha: parallel {
>>   a.text = 'hello';
>> }
>> beta: parallel {
>>   a.text += ' world';
>> }
>> console.log(a);
>> ```
>>
>> This has racing:
>> * around `a.text` between `alpha:` and `beta:`.
>> * around `console.log` since `a` could be 1 of 3 values depending on how
>> threads are scheduled.
>>
>> I am stating that such racing/shared mutation should be prevented.
>> Workers do this by message passing and ownership of transferable data.
>> There could be other mechanics for synchronization, but I don't see a
>> simplistic solution. Things like having a read-only view of data partially
>> helps, but atomics are most likely the proper way to do this if you don't
>> want message passing and ownership semantics.
>>
>> On Wed, Nov 2, 2016 at 9:09 AM, Leo Dutra  wrote:
>>
>>> ​There's nothing about threading that is not problem with Event loop.
>>> I'd say there's even less problems.
>>>
>>> The proposal is a seamless behaviour, equals to what we have now.
>>>
>>> Message passing is not a problem of JS developer in the case, but a
>>> V8/WhateverMonkey problem.
>>>
>>> Changing a value inside a multithread async MUST behave in the same way
>>> of a change inside a single threaded async. The same way, non-referenced
>>> variables SHALL NOT be scoped in the thread. This is not Java with
>>> volatiles. This is the plain old JS with clojures, openess and loose bare
>>> metal control.
>>>
>>> Thread interruption is a bad practice anyway. And we could have a Mutex
>>> class for the specific case or another idea.
>>>
>>> Workers are evented and started, not pooled and easy to use.
>>> ​
>>>
>>>
>>> *Leo Dutra, **on **Facebook  **and 
>>> LinkedIn
>>> *
>>>
>>> 2016-11-02 11:57 GMT-02:00 Bradley Meck :
>>>
 We need to be careful about this, I would never condone adding
 threading that could share variables that were not intended to be
 multi-threaded, as such variable access outside of your `parallelize`
 construct/syntax would need to be message passing when talking to something
 that is not already written as a parallel structure. A notable thing here
 is that Shared Memory and Atomics that are in ECMA Stage 2 :
 https://github.com/tc39/ecmascript_sharedmem which would probably need
 to land prior to me condoning any shared mutable state.

 Historically, all JS implementations are based upon a job queueing
 system described by the Event Loop. This is very different from parallelism
 which could have shared mutable state. All code is guaranteed to have
 exclusive access to variables in scope until it finishes running, and that
 the content of those variables will not change from preemption (there are
 cases where this is not true in the browser with a live DOM). There are
 alternative discussion recently on Workers :
 https://esdiscuss.org/topic/standardize-es-worker . I might look there
 first.

 In particular, I would suggest taking a look at problems of
 synchronization, locking, and preemption breaking existing code a bit
 rather than just stating that green threads are the way to go.

 On Wed, Nov 2, 2016 at 8:45 AM, Leo Dutra 
 wrote:

> ECMA introduced Promises and async-await in JS. This improves coding
> in an amazing way, reducing the control developers need to wrap an AJAX
> call or async I/O.
>
> JavaScript used to be script and not a language. Classes, workers,
> sound control, GL rendering, Node.js modules (with OS conversation),
> incredible GC strategies and compilation on V8 and Mozilla 

Re: Conditional object properties

[Reinis Ivanovs]

No need for new syntax, you can just do this:

```
{...cond ? {prop: value} : null}
```

I find it about the same in readability.

On Wed, Nov 2, 2016 at 2:18 PM, Luke Mitchell  wrote:

> Hi all,
>
> I often come across a situation where I wish to extend an object
> (usually an argument for an API request) if a particular condition is
> satisfied, such as the presence of a function parameter. Currently the
> only way to do this is by assigning the object to a variable, checking
> the condition using an `if` statement and then extending the object. I
> am proposing the inclusion of an operator that allows a property to be
> included, subject to a particular condition, inside the object
> definition.
>
> The operator looks like this:
>
> ```
> let obj = {
>   cond ? prop: value
> };
>
> ```
>
> The operator could also be used with a block statement, allowing
> multiple properties to be included:
>
> ```
> let obj = {
>   cond ? {
> prop1: value1,
> prop2: value2
>   }
> };
> ```
>
> I have created a draft proposal and would love to hear any thoughts
> you have on the matter. You can find it on my GitHub, at the link
> below.
>
> https://github.com/lukem512/proposal-condition-property-definitions
>
> Kind regards,
> Luke
> ___
> 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]

If it is accepted, yes... Atomics should take care of racing.

We have a lighter context than most functional languages with this
proposal: we reassure JavaScript memory is totally mutable (against
Erlang/Rust/Haskell).

This keeps the job easier. I was thinking in the worst possibility and we
have the easier.

Lock, immutability and not shared mutation are the special cases.
For these cases, Atomic and Mutex constructs will fit.


*Leo Dutra, **on **Facebook 
**and LinkedIn
*

2016-11-02 12:27 GMT-02:00 Bradley Meck :

> Consider:
>
> ```
> let a = {};
>
> alpha: parallel {
>   a.text = 'hello';
> }
> beta: parallel {
>   a.text += ' world';
> }
> console.log(a);
> ```
>
> This has racing:
> * around `a.text` between `alpha:` and `beta:`.
> * around `console.log` since `a` could be 1 of 3 values depending on how
> threads are scheduled.
>
> I am stating that such racing/shared mutation should be prevented. Workers
> do this by message passing and ownership of transferable data. There could
> be other mechanics for synchronization, but I don't see a simplistic
> solution. Things like having a read-only view of data partially helps, but
> atomics are most likely the proper way to do this if you don't want message
> passing and ownership semantics.
>
> On Wed, Nov 2, 2016 at 9:09 AM, Leo Dutra  wrote:
>
>> ​There's nothing about threading that is not problem with Event loop.
>> I'd say there's even less problems.
>>
>> The proposal is a seamless behaviour, equals to what we have now.
>>
>> Message passing is not a problem of JS developer in the case, but a
>> V8/WhateverMonkey problem.
>>
>> Changing a value inside a multithread async MUST behave in the same way
>> of a change inside a single threaded async. The same way, non-referenced
>> variables SHALL NOT be scoped in the thread. This is not Java with
>> volatiles. This is the plain old JS with clojures, openess and loose bare
>> metal control.
>>
>> Thread interruption is a bad practice anyway. And we could have a Mutex
>> class for the specific case or another idea.
>>
>> Workers are evented and started, not pooled and easy to use.
>> ​
>>
>>
>> *Leo Dutra, **on **Facebook  **and 
>> LinkedIn
>> *
>>
>> 2016-11-02 11:57 GMT-02:00 Bradley Meck :
>>
>>> We need to be careful about this, I would never condone adding threading
>>> that could share variables that were not intended to be multi-threaded, as
>>> such variable access outside of your `parallelize` construct/syntax would
>>> need to be message passing when talking to something that is not already
>>> written as a parallel structure. A notable thing here is that Shared Memory
>>> and Atomics that are in ECMA Stage 2 : https://github.com/tc39/ecma
>>> script_sharedmem which would probably need to land prior to me
>>> condoning any shared mutable state.
>>>
>>> Historically, all JS implementations are based upon a job queueing
>>> system described by the Event Loop. This is very different from parallelism
>>> which could have shared mutable state. All code is guaranteed to have
>>> exclusive access to variables in scope until it finishes running, and that
>>> the content of those variables will not change from preemption (there are
>>> cases where this is not true in the browser with a live DOM). There are
>>> alternative discussion recently on Workers :
>>> https://esdiscuss.org/topic/standardize-es-worker . I might look there
>>> first.
>>>
>>> In particular, I would suggest taking a look at problems of
>>> synchronization, locking, and preemption breaking existing code a bit
>>> rather than just stating that green threads are the way to go.
>>>
>>> On Wed, Nov 2, 2016 at 8:45 AM, Leo Dutra  wrote:
>>>
 ECMA introduced Promises and async-await in JS. This improves coding in
 an amazing way, reducing the control developers need to wrap an AJAX call
 or async I/O.

 JavaScript used to be script and not a language. Classes, workers,
 sound control, GL rendering, Node.js modules (with OS conversation),
 incredible GC strategies and compilation on V8 and Mozilla "monkeys"... the
 list goes on and on.

 Almost all the features provided by old mature platforms, like Java,
 .NET and etc. For browsers, the newest JS features provide consistent tools
 for productivity and quality code.

 But there's a huge step to accomplish.

 ECMA introduced workers. Node.js came up with streams, native process
 spawn and libuv thread pool. This is a lot, but not enough.

 All I hear about Node.js is how it is great for quick message I/O and
 bad for aggregations and impossible for parallel tasking. Again, we have
 workers and processes, but not green threads.

 I invite you to take a quick look 

Re: Conditional object properties

[Boris Zbarsky]

On 11/2/16 9:04 AM, kdex wrote:

I'd imagine that from an engine point of view, this means that fewer
object shapes land in memory, at least for v8.


I'm pretty sure it means nothing of the sort in SpiderMonkey (in terms 
of memory usage, not in terms of object shapes that flow through 
subsequent shape guards), for what it's worth.  I'm not sure it's worth 
adding things to the standard just to work around implementation quirks 
of a specific implementation.


No opinion on the ergonomics argument.


Reducing the number of object shapes currently boils down to using an
object literal and setting the properties to `value || null` instead of
extending the object with new properties imperatively.


This actually creates _more_ object shapes in SpiderMonkey, I believe, 
though fewer shapes that flow through code locations.  So it depends on 
whether you're trying to optimize memory usage or performance.  And of 
course on whether you're tuning to a particular engine's current 
implementation strategy...


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Bradley Meck]

Consider:

```
let a = {};

alpha: parallel {
  a.text = 'hello';
}
beta: parallel {
  a.text += ' world';
}
console.log(a);
```

This has racing:
* around `a.text` between `alpha:` and `beta:`.
* around `console.log` since `a` could be 1 of 3 values depending on how
threads are scheduled.

I am stating that such racing/shared mutation should be prevented. Workers
do this by message passing and ownership of transferable data. There could
be other mechanics for synchronization, but I don't see a simplistic
solution. Things like having a read-only view of data partially helps, but
atomics are most likely the proper way to do this if you don't want message
passing and ownership semantics.

On Wed, Nov 2, 2016 at 9:09 AM, Leo Dutra  wrote:

> ​There's nothing about threading that is not problem with Event loop.
> I'd say there's even less problems.
>
> The proposal is a seamless behaviour, equals to what we have now.
>
> Message passing is not a problem of JS developer in the case, but a
> V8/WhateverMonkey problem.
>
> Changing a value inside a multithread async MUST behave in the same way of
> a change inside a single threaded async. The same way, non-referenced
> variables SHALL NOT be scoped in the thread. This is not Java with
> volatiles. This is the plain old JS with clojures, openess and loose bare
> metal control.
>
> Thread interruption is a bad practice anyway. And we could have a Mutex
> class for the specific case or another idea.
>
> Workers are evented and started, not pooled and easy to use.
> ​
>
>
> *Leo Dutra, **on **Facebook  **and 
> LinkedIn
> *
>
> 2016-11-02 11:57 GMT-02:00 Bradley Meck :
>
>> We need to be careful about this, I would never condone adding threading
>> that could share variables that were not intended to be multi-threaded, as
>> such variable access outside of your `parallelize` construct/syntax would
>> need to be message passing when talking to something that is not already
>> written as a parallel structure. A notable thing here is that Shared Memory
>> and Atomics that are in ECMA Stage 2 : https://github.com/tc39/ecma
>> script_sharedmem which would probably need to land prior to me condoning
>> any shared mutable state.
>>
>> Historically, all JS implementations are based upon a job queueing system
>> described by the Event Loop. This is very different from parallelism which
>> could have shared mutable state. All code is guaranteed to have exclusive
>> access to variables in scope until it finishes running, and that the
>> content of those variables will not change from preemption (there are cases
>> where this is not true in the browser with a live DOM). There are
>> alternative discussion recently on Workers : https://esdiscuss.org/topic/
>> standardize-es-worker . I might look there first.
>>
>> In particular, I would suggest taking a look at problems of
>> synchronization, locking, and preemption breaking existing code a bit
>> rather than just stating that green threads are the way to go.
>>
>> On Wed, Nov 2, 2016 at 8:45 AM, Leo Dutra  wrote:
>>
>>> ECMA introduced Promises and async-await in JS. This improves coding in
>>> an amazing way, reducing the control developers need to wrap an AJAX call
>>> or async I/O.
>>>
>>> JavaScript used to be script and not a language. Classes, workers, sound
>>> control, GL rendering, Node.js modules (with OS conversation), incredible
>>> GC strategies and compilation on V8 and Mozilla "monkeys"... the list goes
>>> on and on.
>>>
>>> Almost all the features provided by old mature platforms, like Java,
>>> .NET and etc. For browsers, the newest JS features provide consistent tools
>>> for productivity and quality code.
>>>
>>> But there's a huge step to accomplish.
>>>
>>> ECMA introduced workers. Node.js came up with streams, native process
>>> spawn and libuv thread pool. This is a lot, but not enough.
>>>
>>> All I hear about Node.js is how it is great for quick message I/O and
>>> bad for aggregations and impossible for parallel tasking. Again, we have
>>> workers and processes, but not green threads.
>>>
>>> I invite you to take a quick look at Akka and OTP (Erlang). More than
>>> it, I will argument: workers and process spawn are the latent desire for
>>> parallel and starting one of these are not "cheap" or waiting in a pool.
>>>
>>> We use streams extensively in Node.js and most frameworks hides it from
>>> us. Call it magic, I call it pragmatism.
>>>
>>> Now, async, await, Promises ("Futures")... we can make it all work in
>>> parallel.
>>>
>>> This would explore more libuv in Node.js and browsers could handle it
>>> too, seamlessly.
>>>
>>> Each function could be run in a green thread, pulled from a
>>> browser/libuv pool, allowing Node.js and browsers to process aggregations
>>> and heavy rendering without heavy start costs and complicated message
>>> control through 

Re: Proposal of Multithread JavaScript

[Leo Dutra]

​Understood about shared mem. I agree a declared shared space is faster and
more manageable than a considering all shared.

As I said, we could use JIT to determine that or use the long reserved word
"volatile":
volatile var foo = "Shared string"

Accessing a non-volatile variable SHALL resolve to a copy like all the
other platforms resolve.

I don't like to refer to others, but this is a problem industry resolved a
long time ago.
​


*Leo Dutra, **on **Facebook 
**and LinkedIn
*

2016-11-02 12:22 GMT-02:00 Leo Dutra :

> Understood about shared mem. I agree a declared shared space is faster and
> more manageable than a considering all shared.
>
> As I said, we could use JIT to determine that or use the long reserved
> word "volatile":
> volatile var foo = "Shared string"
>
> Accessing a non-volatile variable SHALL resolve to a copy like all the
> other platforms resolve.
>
> I don't like to refer to others, but this is a problem industry resolved a
> long time ago.
>
>
>
>
>
> *Leo Dutra, **on **Facebook  **and 
> LinkedIn
> *
>
> 2016-11-02 11:57 GMT-02:00 Bradley Meck :
>
>> We need to be careful about this, I would never condone adding threading
>> that could share variables that were not intended to be multi-threaded, as
>> such variable access outside of your `parallelize` construct/syntax would
>> need to be message passing when talking to something that is not already
>> written as a parallel structure. A notable thing here is that Shared Memory
>> and Atomics that are in ECMA Stage 2 : https://github.com/tc39/ecma
>> script_sharedmem which would probably need to land prior to me condoning
>> any shared mutable state.
>>
>> Historically, all JS implementations are based upon a job queueing system
>> described by the Event Loop. This is very different from parallelism which
>> could have shared mutable state. All code is guaranteed to have exclusive
>> access to variables in scope until it finishes running, and that the
>> content of those variables will not change from preemption (there are cases
>> where this is not true in the browser with a live DOM). There are
>> alternative discussion recently on Workers : https://esdiscuss.org/topic/
>> standardize-es-worker . I might look there first.
>>
>> In particular, I would suggest taking a look at problems of
>> synchronization, locking, and preemption breaking existing code a bit
>> rather than just stating that green threads are the way to go.
>>
>> On Wed, Nov 2, 2016 at 8:45 AM, Leo Dutra  wrote:
>>
>>> ECMA introduced Promises and async-await in JS. This improves coding in
>>> an amazing way, reducing the control developers need to wrap an AJAX call
>>> or async I/O.
>>>
>>> JavaScript used to be script and not a language. Classes, workers, sound
>>> control, GL rendering, Node.js modules (with OS conversation), incredible
>>> GC strategies and compilation on V8 and Mozilla "monkeys"... the list goes
>>> on and on.
>>>
>>> Almost all the features provided by old mature platforms, like Java,
>>> .NET and etc. For browsers, the newest JS features provide consistent tools
>>> for productivity and quality code.
>>>
>>> But there's a huge step to accomplish.
>>>
>>> ECMA introduced workers. Node.js came up with streams, native process
>>> spawn and libuv thread pool. This is a lot, but not enough.
>>>
>>> All I hear about Node.js is how it is great for quick message I/O and
>>> bad for aggregations and impossible for parallel tasking. Again, we have
>>> workers and processes, but not green threads.
>>>
>>> I invite you to take a quick look at Akka and OTP (Erlang). More than
>>> it, I will argument: workers and process spawn are the latent desire for
>>> parallel and starting one of these are not "cheap" or waiting in a pool.
>>>
>>> We use streams extensively in Node.js and most frameworks hides it from
>>> us. Call it magic, I call it pragmatism.
>>>
>>> Now, async, await, Promises ("Futures")... we can make it all work in
>>> parallel.
>>>
>>> This would explore more libuv in Node.js and browsers could handle it
>>> too, seamlessly.
>>>
>>> Each function could be run in a green thread, pulled from a
>>> browser/libuv pool, allowing Node.js and browsers to process aggregations
>>> and heavy rendering without heavy start costs and complicated message
>>> control through events.
>>>
>>> More, I ask why not, and "single thread nature of JS" looks more like a
>>> bad legacy from old browsers. We can do it in pieces, like the proposed
>>> async-await and, on better days, provide a Parallel API (something like 
>>> *parallelize(()
>>> -> { // parallel stuff here })*).
>>>
>>> I wanna leave you with the possibilities in mind and bully this single
>>> thread dogma.
>>>
>>> You have been told.
>>>
>>> *Leo Dutra, **on **Facebook 

Re: Proposal of Multithread JavaScript

[Leo Dutra]

​There's nothing about threading that is not problem with Event loop.
I'd say there's even less problems.

The proposal is a seamless behaviour, equals to what we have now.

Message passing is not a problem of JS developer in the case, but a
V8/WhateverMonkey problem.

Changing a value inside a multithread async MUST behave in the same way of
a change inside a single threaded async. The same way, non-referenced
variables SHALL NOT be scoped in the thread. This is not Java with
volatiles. This is the plain old JS with clojures, openess and loose bare
metal control.

Thread interruption is a bad practice anyway. And we could have a Mutex
class for the specific case or another idea.

Workers are evented and started, not pooled and easy to use.
​


*Leo Dutra, **on **Facebook 
**and LinkedIn
*

2016-11-02 11:57 GMT-02:00 Bradley Meck :

> We need to be careful about this, I would never condone adding threading
> that could share variables that were not intended to be multi-threaded, as
> such variable access outside of your `parallelize` construct/syntax would
> need to be message passing when talking to something that is not already
> written as a parallel structure. A notable thing here is that Shared Memory
> and Atomics that are in ECMA Stage 2 : https://github.com/tc39/ecma
> script_sharedmem which would probably need to land prior to me condoning
> any shared mutable state.
>
> Historically, all JS implementations are based upon a job queueing system
> described by the Event Loop. This is very different from parallelism which
> could have shared mutable state. All code is guaranteed to have exclusive
> access to variables in scope until it finishes running, and that the
> content of those variables will not change from preemption (there are cases
> where this is not true in the browser with a live DOM). There are
> alternative discussion recently on Workers : https://esdiscuss.org/topic/
> standardize-es-worker . I might look there first.
>
> In particular, I would suggest taking a look at problems of
> synchronization, locking, and preemption breaking existing code a bit
> rather than just stating that green threads are the way to go.
>
> On Wed, Nov 2, 2016 at 8:45 AM, Leo Dutra  wrote:
>
>> ECMA introduced Promises and async-await in JS. This improves coding in
>> an amazing way, reducing the control developers need to wrap an AJAX call
>> or async I/O.
>>
>> JavaScript used to be script and not a language. Classes, workers, sound
>> control, GL rendering, Node.js modules (with OS conversation), incredible
>> GC strategies and compilation on V8 and Mozilla "monkeys"... the list goes
>> on and on.
>>
>> Almost all the features provided by old mature platforms, like Java, .NET
>> and etc. For browsers, the newest JS features provide consistent tools for
>> productivity and quality code.
>>
>> But there's a huge step to accomplish.
>>
>> ECMA introduced workers. Node.js came up with streams, native process
>> spawn and libuv thread pool. This is a lot, but not enough.
>>
>> All I hear about Node.js is how it is great for quick message I/O and bad
>> for aggregations and impossible for parallel tasking. Again, we have
>> workers and processes, but not green threads.
>>
>> I invite you to take a quick look at Akka and OTP (Erlang). More than it,
>> I will argument: workers and process spawn are the latent desire for
>> parallel and starting one of these are not "cheap" or waiting in a pool.
>>
>> We use streams extensively in Node.js and most frameworks hides it from
>> us. Call it magic, I call it pragmatism.
>>
>> Now, async, await, Promises ("Futures")... we can make it all work in
>> parallel.
>>
>> This would explore more libuv in Node.js and browsers could handle it
>> too, seamlessly.
>>
>> Each function could be run in a green thread, pulled from a browser/libuv
>> pool, allowing Node.js and browsers to process aggregations and heavy
>> rendering without heavy start costs and complicated message control through
>> events.
>>
>> More, I ask why not, and "single thread nature of JS" looks more like a
>> bad legacy from old browsers. We can do it in pieces, like the proposed
>> async-await and, on better days, provide a Parallel API (something like 
>> *parallelize(()
>> -> { // parallel stuff here })*).
>>
>> I wanna leave you with the possibilities in mind and bully this single
>> thread dogma.
>>
>> You have been told.
>>
>> *Leo Dutra, **on **Facebook  **and 
>> LinkedIn
>> *
>>
>> ___
>> 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]

We need to be careful about this, I would never condone adding threading
that could share variables that were not intended to be multi-threaded, as
such variable access outside of your `parallelize` construct/syntax would
need to be message passing when talking to something that is not already
written as a parallel structure. A notable thing here is that Shared Memory
and Atomics that are in ECMA Stage 2 : https://github.com/tc39/
ecmascript_sharedmem which would probably need to land prior to me
condoning any shared mutable state.

Historically, all JS implementations are based upon a job queueing system
described by the Event Loop. This is very different from parallelism which
could have shared mutable state. All code is guaranteed to have exclusive
access to variables in scope until it finishes running, and that the
content of those variables will not change from preemption (there are cases
where this is not true in the browser with a live DOM). There are
alternative discussion recently on Workers : https://esdiscuss.org/topic/
standardize-es-worker . I might look there first.

In particular, I would suggest taking a look at problems of
synchronization, locking, and preemption breaking existing code a bit
rather than just stating that green threads are the way to go.

On Wed, Nov 2, 2016 at 8:45 AM, Leo Dutra  wrote:

> ECMA introduced Promises and async-await in JS. This improves coding in an
> amazing way, reducing the control developers need to wrap an AJAX call or
> async I/O.
>
> JavaScript used to be script and not a language. Classes, workers, sound
> control, GL rendering, Node.js modules (with OS conversation), incredible
> GC strategies and compilation on V8 and Mozilla "monkeys"... the list goes
> on and on.
>
> Almost all the features provided by old mature platforms, like Java, .NET
> and etc. For browsers, the newest JS features provide consistent tools for
> productivity and quality code.
>
> But there's a huge step to accomplish.
>
> ECMA introduced workers. Node.js came up with streams, native process
> spawn and libuv thread pool. This is a lot, but not enough.
>
> All I hear about Node.js is how it is great for quick message I/O and bad
> for aggregations and impossible for parallel tasking. Again, we have
> workers and processes, but not green threads.
>
> I invite you to take a quick look at Akka and OTP (Erlang). More than it,
> I will argument: workers and process spawn are the latent desire for
> parallel and starting one of these are not "cheap" or waiting in a pool.
>
> We use streams extensively in Node.js and most frameworks hides it from
> us. Call it magic, I call it pragmatism.
>
> Now, async, await, Promises ("Futures")... we can make it all work in
> parallel.
>
> This would explore more libuv in Node.js and browsers could handle it too,
> seamlessly.
>
> Each function could be run in a green thread, pulled from a browser/libuv
> pool, allowing Node.js and browsers to process aggregations and heavy
> rendering without heavy start costs and complicated message control through
> events.
>
> More, I ask why not, and "single thread nature of JS" looks more like a
> bad legacy from old browsers. We can do it in pieces, like the proposed
> async-await and, on better days, provide a Parallel API (something like 
> *parallelize(()
> -> { // parallel stuff here })*).
>
> I wanna leave you with the possibilities in mind and bully this single
> thread dogma.
>
> You have been told.
>
> *Leo Dutra, **on **Facebook  **and 
> LinkedIn
> *
>
> ___
> 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]

*TL;DR:*

(function foo() { ... })()   // sync and single threaded
(*async *function() { ... })() // async and parallel

Additional:
parallel.run()
parallel.stream()
parallel.sleep()
parallel.waterfall()
...



*Leo Dutra, **on **Facebook 
**and LinkedIn
*

2016-11-02 11:38 GMT-02:00 Leo Dutra :

> ECMA introduced Promises and async-await in JS. This improves coding in an
> amazing way, reducing the control developers need to wrap an AJAX call or
> async I/O.
>
> JavaScript used to be script and not a language. Classes, workers, sound
> control, GL rendering, Node.js modules (with OS conversation), incredible
> GC strategies and compilation on V8 and Mozilla "monkeys"... the list goes
> on and on.
>
> Almost all the features provided by old mature platforms, like Java, .NET
> and etc. For browsers, the newest JS features provide consistent tools for
> productivity and quality code.
>
> But there's a huge step to accomplish.
>
> ECMA introduced workers. Node.js came up with streams, native process
> spawn and libuv thread pool. This is a lot, but not enough.
>
> All I hear about Node.js is how it is great for quick message I/O and bad
> for aggregations and impossible for parallel tasking. Again, we have
> workers and processes, but not green threads.
>
> I invite you to take a quick look at Akka and OTP (Erlang). More than it,
> I will argument: workers and process spawn are the latent desire for
> parallel and starting one of these are not "cheap" or waiting in a pool.
>
> We use streams extensively in Node.js and most frameworks hides it from
> us. Call it magic, I call it pragmatism.
>
> Now, async, await, Promises ("Futures")... we can make it all work in
> parallel.
>
> This would explore more libuv in Node.js and browsers could handle it too,
> seamlessly.
>
> Each function could be run in a green thread, pulled from a browser/libuv
> pool, allowing Node.js and browsers to process aggregations and heavy
> rendering without heavy start costs and complicated message control through
> events.
>
> More, I ask why not, and "single thread nature of JS" looks more like a
> bad legacy from old browsers. We can do it in pieces, like the proposed
> async-await and, on better days, provide a Parallel API (something like 
> *parallelize(()
> -> { // parallel stuff here })*).
>
> I wanna leave you with the possibilities in mind and bully this single
> thread dogma.
>
> You have been told.
>
>
> *Leo Dutra, **on **Facebook  **and 
> LinkedIn
> *
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Proposal of Multithread JavaScript

[Leo Dutra]

ECMA introduced Promises and async-await in JS. This improves coding in an
amazing way, reducing the control developers need to wrap an AJAX call or
async I/O.

JavaScript used to be script and not a language. Classes, workers, sound
control, GL rendering, Node.js modules (with OS conversation), incredible
GC strategies and compilation on V8 and Mozilla "monkeys"... the list goes
on and on.

Almost all the features provided by old mature platforms, like Java, .NET
and etc. For browsers, the newest JS features provide consistent tools for
productivity and quality code.

But there's a huge step to accomplish.

ECMA introduced workers. Node.js came up with streams, native process spawn
and libuv thread pool. This is a lot, but not enough.

All I hear about Node.js is how it is great for quick message I/O and bad
for aggregations and impossible for parallel tasking. Again, we have
workers and processes, but not green threads.

I invite you to take a quick look at Akka and OTP (Erlang). More than it, I
will argument: workers and process spawn are the latent desire for parallel
and starting one of these are not "cheap" or waiting in a pool.

We use streams extensively in Node.js and most frameworks hides it from us.
Call it magic, I call it pragmatism.

Now, async, await, Promises ("Futures")... we can make it all work in
parallel.

This would explore more libuv in Node.js and browsers could handle it too,
seamlessly.

Each function could be run in a green thread, pulled from a browser/libuv
pool, allowing Node.js and browsers to process aggregations and heavy
rendering without heavy start costs and complicated message control through
events.

More, I ask why not, and "single thread nature of JS" looks more like a bad
legacy from old browsers. We can do it in pieces, like the proposed
async-await and, on better days, provide a Parallel API (something
like *parallelize(()
-> { // parallel stuff here })*).

I wanna leave you with the possibilities in mind and bully this single
thread dogma.

You have been told.

*Leo Dutra, **on **Facebook 
**and LinkedIn
*
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Conditional object properties

[Luke Mitchell]

Aside from performance, the operator also leads to denser code which is easier 
to write. Talking to my colleagues, I was told that two of them could have used 
it already this morning!

Luke Mitchell

Luke Mitchell

Software Developer

On Wed, 02 Nov 2016 at 13:12 Isiah Meadows

<
mailto:Isiah Meadows 
> wrote:

a, pre, code, a:link, body { word-wrap: break-word !important; }

That's not likely to make any serious performance difference with an ajax call. 
And in tight loops, I try avoid conditionals and object creation anyways, to 
avoid branch prediction fails (in both the engine and CPU) and costly 
allocation. (Most engines only do a limited form of pooling for faster GC.)

On Wed, Nov 2, 2016, 09:04 kdex <
mailto:k...@kdex.de
> wrote:

I'd imagine that from an engine point of view, this means that fewer

object shapes land in memory, at least for v8.

Reducing the number of object shapes currently boils down to using an

object literal and setting the properties to `value || null` instead of

extending the object with new properties imperatively.

On Wednesday, November 2, 2016 12:38:05 PM CET Isiah Meadows wrote:

> What benefit would this bring over imperatively adding properties?

>

> On Wed, Nov 2, 2016, 08:18 Luke Mitchell <
mailto:l...@enki.com
> wrote:

>

> > Hi all,

> >

> > I often come across a situation where I wish to extend an object

> > (usually an argument for an API request) if a particular condition is

> > satisfied, such as the presence of a function parameter. Currently the

> > only way to do this is by assigning the object to a variable, checking

> > the condition using an `if` statement and then extending the object. I

> > am proposing the inclusion of an operator that allows a property to be

> > included, subject to a particular condition, inside the object

> > definition.

> >

> > The operator looks like this:

> >

> > ```

> > let obj = {

> >   cond ? prop: value

> > };

> >

> > ```

> >

> > The operator could also be used with a block statement, allowing

> > multiple properties to be included:

> >

> > ```

> > let obj = {

> >   cond ? {

> >     prop1: value1,

> >     prop2: value2

> >   }

> > };

> > ```

> >

> > I have created a draft proposal and would love to hear any thoughts

> > you have on the matter. You can find it on my GitHub, at the link

> > below.

> >

> >
https://github.com/lukem512/proposal-condition-property-definitions
> >

> > Kind regards,

> > Luke

> > ___

> > es-discuss mailing list

> >
mailto:es-discuss@mozilla.org
> >
https://mail.mozilla.org/listinfo/es-discuss
> >

>

___

es-discuss mailing list
mailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

___

es-discuss mailing list
mailto: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: Conditional object properties

[Isiah Meadows]

That's not likely to make any serious performance difference with an ajax
call. And in tight loops, I try avoid conditionals and object creation
anyways, to avoid branch prediction fails (in both the engine and CPU) and
costly allocation. (Most engines only do a limited form of pooling for
faster GC.)

On Wed, Nov 2, 2016, 09:04 kdex  wrote:

> I'd imagine that from an engine point of view, this means that fewer
> object shapes land in memory, at least for v8.
>
> Reducing the number of object shapes currently boils down to using an
> object literal and setting the properties to `value || null` instead of
> extending the object with new properties imperatively.
>
> On Wednesday, November 2, 2016 12:38:05 PM CET Isiah Meadows wrote:
> > What benefit would this bring over imperatively adding properties?
> >
> > On Wed, Nov 2, 2016, 08:18 Luke Mitchell  wrote:
> >
> > > Hi all,
> > >
> > > I often come across a situation where I wish to extend an object
> > > (usually an argument for an API request) if a particular condition is
> > > satisfied, such as the presence of a function parameter. Currently the
> > > only way to do this is by assigning the object to a variable, checking
> > > the condition using an `if` statement and then extending the object. I
> > > am proposing the inclusion of an operator that allows a property to be
> > > included, subject to a particular condition, inside the object
> > > definition.
> > >
> > > The operator looks like this:
> > >
> > > ```
> > > let obj = {
> > >   cond ? prop: value
> > > };
> > >
> > > ```
> > >
> > > The operator could also be used with a block statement, allowing
> > > multiple properties to be included:
> > >
> > > ```
> > > let obj = {
> > >   cond ? {
> > > prop1: value1,
> > > prop2: value2
> > >   }
> > > };
> > > ```
> > >
> > > I have created a draft proposal and would love to hear any thoughts
> > > you have on the matter. You can find it on my GitHub, at the link
> > > below.
> > >
> > > https://github.com/lukem512/proposal-condition-property-definitions
> > >
> > > Kind regards,
> > > Luke
> > > ___
> > > 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: Conditional object properties

[kdex]

I'd imagine that from an engine point of view, this means that fewer
object shapes land in memory, at least for v8.

Reducing the number of object shapes currently boils down to using an
object literal and setting the properties to `value || null` instead of
extending the object with new properties imperatively.

On Wednesday, November 2, 2016 12:38:05 PM CET Isiah Meadows wrote:
> What benefit would this bring over imperatively adding properties?
> 
> On Wed, Nov 2, 2016, 08:18 Luke Mitchell  wrote:
> 
> > Hi all,
> >
> > I often come across a situation where I wish to extend an object
> > (usually an argument for an API request) if a particular condition is
> > satisfied, such as the presence of a function parameter. Currently the
> > only way to do this is by assigning the object to a variable, checking
> > the condition using an `if` statement and then extending the object. I
> > am proposing the inclusion of an operator that allows a property to be
> > included, subject to a particular condition, inside the object
> > definition.
> >
> > The operator looks like this:
> >
> > ```
> > let obj = {
> >   cond ? prop: value
> > };
> >
> > ```
> >
> > The operator could also be used with a block statement, allowing
> > multiple properties to be included:
> >
> > ```
> > let obj = {
> >   cond ? {
> > prop1: value1,
> > prop2: value2
> >   }
> > };
> > ```
> >
> > I have created a draft proposal and would love to hear any thoughts
> > you have on the matter. You can find it on my GitHub, at the link
> > below.
> >
> > https://github.com/lukem512/proposal-condition-property-definitions
> >
> > Kind regards,
> > Luke
> > ___
> > 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: Conditional object properties

[Isiah Meadows]

What benefit would this bring over imperatively adding properties?

On Wed, Nov 2, 2016, 08:18 Luke Mitchell  wrote:

> Hi all,
>
> I often come across a situation where I wish to extend an object
> (usually an argument for an API request) if a particular condition is
> satisfied, such as the presence of a function parameter. Currently the
> only way to do this is by assigning the object to a variable, checking
> the condition using an `if` statement and then extending the object. I
> am proposing the inclusion of an operator that allows a property to be
> included, subject to a particular condition, inside the object
> definition.
>
> The operator looks like this:
>
> ```
> let obj = {
>   cond ? prop: value
> };
>
> ```
>
> The operator could also be used with a block statement, allowing
> multiple properties to be included:
>
> ```
> let obj = {
>   cond ? {
> prop1: value1,
> prop2: value2
>   }
> };
> ```
>
> I have created a draft proposal and would love to hear any thoughts
> you have on the matter. You can find it on my GitHub, at the link
> below.
>
> https://github.com/lukem512/proposal-condition-property-definitions
>
> Kind regards,
> Luke
> ___
> 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: Another statement expression-related proposal

[Isiah Meadows]

Inline.

On Wed, Nov 2, 2016, 01:01 Bob Myers  wrote:

> Just a random thought, but would `{= =}` work for expression blocks?
>
> ```js
> // plain block
> const foo = {= let a = 1; a =};
>
> assert.equal(foo, 1)
>
> // if-else
> let cond = false
> const bar = {= if (cond) "hi" else "bye" =};
>
> assert.equal(bar, "bye")
>
> // try-catch
> let e = new Error()
> const error = {= try { throw e } catch (e) { e } =};
> assert.equal(error, e)
> ```
>

In theory, yes, but it doesn't exactly look very pretty (too many equals
signs and curly braces).


>
> I don't know about the loop idea. It seems like it's trying to do too much.
>

The loop thing is a bit extra, complicating things some, but I feel it's
merited by the ability to avoid a lot of the confusion when using loops
with the current `do` expression proposal (loops currently act like
`reduce`, which is incredibly unintuitive).


> On Wed, Nov 2, 2016 at 10:13 AM, Isiah Meadows 
> wrote:
>
> Yes, there's been a bit of talk about modifying the `do` proposal in
> various ways (like allowing more than a block, using `=` to
> differentiate, etc.), but each of these have potential ambiguities
> (like conflicting with `do-while` or object literal syntax,
> respectively), and give unintuitive results with loops.
>
> Here's my idea: prepend a `::` to any non-expression statement, and it
> becomes an expression. The last statement's value (as if through
> `eval`) is used as the return value, with exception of loops, which
> return an array generated from their loop body. Here's a few examples
> to clarify:
>
> ```js
> // plain block
> const foo = :: { let a = 1; a }
> assert.equal(foo, 1)
>
> // if-else
> let cond = false
> const bar = :: if (cond) "hi" else "bye"
> assert.equal(bar, "bye")
>
> // try-catch
> let e = new Error()
> const error = :: try { throw e } catch (e) { e }
> assert.equal(error, e)
>
> // while loop
> let i = 0
> const range = :: while (i < 10) i++
> assert.deepEqual(range, [
>   0, 1, 2, 3, 4, 5, 6, 7, 8, 9,
> ])
>
> // for + nested if-else
> const fizzBuzz = :: for (let i = 0; i < 100; i++) {
>   if (i % 15) "FizzBuzz"
>   else if (i % 3) "Fizz"
>   else if (i % 5) "Buzz"
>   // If no expression is evaluated in the body, then no value
>   // is pushed.
> }
> assert.deepEqual(fizzBuzz, [
>   // 100 lines of the classic "Fizz", "Buzz", and "FizzBuzz"
> ])
> ```
>
> What do you all think of this?
>
> ---
>
> To clarify, here's some more detailed semantics:
>
> ### Grammar
>
> - `:: ExpressionStatement`
> - `:: Declaration`
> - `:: VariableStatement`
>
> These are early errors, and they are all redundant, anyways, since you
> already have a value you could use.
>
> - `:: ContinueStatement`
> - `:: BreakStatement`
> - `:: ReturnStatement`
> - `:: DebuggerStatement`
> - `:: ThrowStatement`
> - `:: EmptyStatement`
>
> These are also early errors, since there's no real value you can
> associate with them.
>
> - `:: BlockStatement`
> - `:: IfStatement`
> - `:: SwitchStatement`
> - `:: WithStatement`
> - `:: TryStatement`
>
> 1. Let `completion` be ? ExecuteStatement(`statement`), where
> `statement` is one of the statements above.
> 2. If `completion` is *none*, return `undefined`
> 3. Otherwise, return `completion`.
>
> - `:: IterationStatement`
>
> 1. Return ? ExecuteIterationStatement(`statement`), where `statement`
> is one of the statements above.
>
> - `:: LabelledStatement`
>
> This works similarly, but has an outer label instead. The same above
> statements are also similarly banned as `LabelledItem` entries.
> Additionally, the Annex B extension for FunctionDeclaraions are also
> early errors.
>
> (Should these even be allowed? I'm open to making this an early error
> instead.)
>
> ### Abstract Operation ExecuteStatement(`statement`)
>
> 1. If `statement` is an IterationStatement:
>   1. Let `list` be a new empty list.
>   2. Evaluate `statement`, but for each `child` statement:
> 1. Let `result` be ? ExecuteStatement(`child`).
> 2. If `result` is not *empty*, then append `result` to `list`.
>   3. Return `list`.
> 2. If `statement` is an ExpressionStatement:
>   1. Return the result of evaluating the expression within.
> 3. If `statement` is a `BreakStatement` or `ContinueStatement`:
>   1. Evaluate `statement`
>   2. Return *empty*.
> 4. If `statement` is a `Declaration`:
>   1. Evaluate `statement`.
>   2. Return the value of the resulting declaration
> 5. Otherwise:
>   1. Let `last` be *empty*
>   2. Evaluate `statement`. For each `child` statement:
> 1. Let `last` be ? ExecuteStatement(`child`).
>   3. Note: `last` is the final expression's value, or `empty` if there
> was no final expression.
>   4. Return `last`.
>
> (I probably missed several edge cases, but this is just a mailing list
> strawman.)
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>

Conditional object properties

[Luke Mitchell]

Hi all,

I often come across a situation where I wish to extend an object
(usually an argument for an API request) if a particular condition is
satisfied, such as the presence of a function parameter. Currently the
only way to do this is by assigning the object to a variable, checking
the condition using an `if` statement and then extending the object. I
am proposing the inclusion of an operator that allows a property to be
included, subject to a particular condition, inside the object
definition.

The operator looks like this:

```
let obj = {
  cond ? prop: value
};

```

The operator could also be used with a block statement, allowing
multiple properties to be included:

```
let obj = {
  cond ? {
prop1: value1,
prop2: value2
  }
};
```

I have created a draft proposal and would love to hear any thoughts
you have on the matter. You can find it on my GitHub, at the link
below.

https://github.com/lukem512/proposal-condition-property-definitions

Kind regards,
Luke
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss