Using Generators in Extended Mode for Co-Routines

Erik Arvidsson erik.arvidsson at gmail.com
Fri Sep 12 06:44:09 PDT 2014


Generators are not implicit strict. Only modules and classes are.
On Sep 12, 2014 6:30 AM, "Carl Smith" <carl.input at gmail.com> wrote:

> It seems that ES6 will allow implicit opt-in for generators, with the body
> of the generator being ES6, so it can yield. It also seems that the plan is
> that the body would be forced into strict mode.
>
> The following currently works in Chrome with Experimental JavaScript
> Features enabled, but would not work in strict mode, as the eval call
> wouldn't execute in the callee's namespace.
>
> function * realm(input) {
>     while (true) {
>         input = yield eval(input);
>     }
> }
>
> var r = realm();
> r.next();
> r.next("var a = 1");
> r.next("console.log(a)");
>
> The above functionality is required in an application I'm currently
> working on, and there's a few features that would use it. There's actually
> a large class of applications that could do so. I'm essentially doing a
> REPL, and REPLs are impossible to implement in strict mode. Any app that
> allows the user to enter code that'll be executed, needs to evaluate source
> strings in a persistent namespace. If that namespace is not `window`, then
> the eval call must live in a scope that can yield flow without destroying
> its local namespace.
>
> Lots of applications could use this ~ web shells, programming lessons and
> games, as well as anything that allows the user to script it.
>
> Is there a story for this kind of application, beyond use V8 and hope
> nothing ever changes?
>
> _______________________________________________
> 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/20140912/16b220f2/attachment.html>


More information about the es-discuss mailing list