> On Oct 26, 2016, at 12:43 AM, es-discuss-request at mozilla.org wrote:
>
> Send es-discuss mailing list submissions to
> es-discuss at mozilla.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.mozilla.org/listinfo/es-discuss
> or, via email, send a message with subject or body 'help' to
> es-discuss-request at mozilla.org
>
> You can reach the person managing the list at
> es-discuss-owner at mozilla.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of es-discuss digest..."
> Today's Topics:
>
> 1. Re: Symbol description inference (Allen Wirfs-Brock)
> 2. Re: Standardize ES Worker (Isiah Meadows)
> 3. Re: Symbol description inference (Alexander Jones)
> 4. Re: Standardize ES Worker (Park Hyeonu)
>
> From: Allen Wirfs-Brock <allen at wirfs-brock.com>
> Subject: Re: Symbol description inference
> Date: October 25, 2016 at 12:04:20 PM EDT
> To: Shahar Or <mightyiampresence at gmail.com>
> Cc: Yarom Shoval <yarom.adi at gmail.com>, es-discuss <es-discuss at mozilla.org>
>
>
> Function name inferencing is possible because function definitions are all syntactic special forms that can be unambiguously identified during parsing.
>
> Symbols creation is just a function call so there is no way to reliably detect it. `Symbol` might aliased to some other name by assignment, a different value other than the Symbol creation function might be assigned to the global `Symbol`, or some alternative declaration of `Symbol` might be in some at the point of use.
>
> Allen
>
>
>
>
>
> From: Isiah Meadows <isiahmeadows at gmail.com>
> Subject: Re: Standardize ES Worker
> Date: October 25, 2016 at 5:04:49 PM EDT
> To: Park Hyeonu <nemo1275 at gmail.com>, es-discuss <es-discuss at mozilla.org>
>
>
> Maybe with modification. I currently feel workers are a bit heavy (with their event driven nature), and they most definitely don't follow the idioms of the modern JavaScript language (very promise heavy).
>
>
> On Sun, Oct 23, 2016, 02:11 Park Hyeonu <nemo1275 at gmail.com <mailto:nemo1275 at gmail.com>> wrote:
> Now we're about to standardize thread-shared memory for EcmaScript(https://github.com/tc39/ecmascript_sharedmem <https://github.com/tc39/ecmascript_sharedmem>). But how about the thread itself?
>
> For this topic, I don't think we should develop another thread spec for ES as we already have a nice one - WebWorker. This spec allows multithreading in web client and it's well-adopted on most modern browsers. So all we need to do is just care some web-specific points of the api. Fortunately it's already `new Worker()` not `new WebWorker()` and not so many points should be fixed for it.
>
> For the case to import web spec to ES spec, there's already a case like this - Typed Array. It's originally standardized in Chronos group as a part of WebGL spec, and adopted to ES later.
>
> The spec I'm mentioning here is html5 apis including WebWorker, MessageChannel, Structured Clone Algorithm, Transferable Object.
>
> Sounds nice, isn't it?
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
>
>
>
> From: Alexander Jones <alex at weej.com>
> Subject: Re: Symbol description inference
> Date: October 25, 2016 at 7:40:45 PM EDT
> To: Allen Wirfs-Brock <allen at wirfs-brock.com>
> Cc: Yarom Shoval <yarom.adi at gmail.com>, es-discuss <es-discuss at mozilla.org>
>
>
> IMO, the real problem that needs solving is macros. Macro-based definition of a symbol could trivially reuse the name.
>
> On Tuesday, 25 October 2016, Allen Wirfs-Brock <allen at wirfs-brock.com <mailto:allen at wirfs-brock.com>> wrote:
> Function name inferencing is possible because function definitions are all syntactic special forms that can be unambiguously identified during parsing.
>
> Symbols creation is just a function call so there is no way to reliably detect it. `Symbol` might aliased to some other name by assignment, a different value other than the Symbol creation function might be assigned to the global `Symbol`, or some alternative declaration of `Symbol` might be in some at the point of use.
>
> Allen
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <javascript:;>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
>
>
>
> From: Park Hyeonu <nemo1275 at gmail.com>
> Subject: Re: Standardize ES Worker
> Date: October 26, 2016 at 12:43:14 AM EDT
> To: Isiah Meadows <isiahmeadows at gmail.com>
> Cc: es-discuss <es-discuss at mozilla.org>
>
>
> I agree that we need additional modification from WebWorker spec. What I mean on the first post is that we (likely) can make standard Worker spec as a (mostly) subset of WebWorker spec so current codes using WebWorker need not to be changed.
>
> Anyway, can you explain it more about mismatch between WebWorker and modern js idioms?
>
>
> 2016. 10. 26. 오전 6:05에 "Isiah Meadows" <isiahmeadows at gmail.com <mailto:isiahmeadows at gmail.com>>님이 작성:
> Maybe with modification. I currently feel workers are a bit heavy (with their event driven nature), and they most definitely don't follow the idioms of the modern JavaScript language (very promise heavy).
>
>
> On Sun, Oct 23, 2016, 02:11 Park Hyeonu <nemo1275 at gmail.com <mailto:nemo1275 at gmail.com>> wrote:
> Now we're about to standardize thread-shared memory for EcmaScript(https://github.com/tc39/ecmascript_sharedmem <https://github.com/tc39/ecmascript_sharedmem>). But how about the thread itself?
>
> For this topic, I don't think we should develop another thread spec for ES as we already have a nice one - WebWorker. This spec allows multithreading in web client and it's well-adopted on most modern browsers. So all we need to do is just care some web-specific points of the api. Fortunately it's already `new Worker()` not `new WebWorker()` and not so many points should be fixed for it.
>
> For the case to import web spec to ES spec, there's already a case like this - Typed Array. It's originally standardized in Chronos group as a part of WebGL spec, and adopted to ES later.
>
> The spec I'm mentioning here is html5 apis including WebWorker, MessageChannel, Structured Clone Algorithm, Transferable Object.
>
> Sounds nice, isn't it?
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20161026/494688c9/attachment-0001.html>
