Re: Reason why generators do not have references to themselves?
On Jan 23, 2014, at 4:49 PM, Brendan Eich bren...@mozilla.com wrote: Domenic Denicola wrote: Task.js is still on JavaScript1.8, and is not ES6-compatible. It won't work with modern browsers, or with Regenerator. Fork and fix, should be easy. I expect a PR would be accepted in due course. SpiderMonkey seems to have ES6 generator support somewhat there (thanks to Andy Wingo), should be all there soon enough. Working on it lately, actually. And using regenerator for the tests (\o/)! Also drastically simplifying the library since the customizable scheduler stuff, while kind of neat, is probably less compelling than a minimal library. Down to under 150 lines, unminified with comments, and still shrinking... Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Reason why generators do not have references to themselves?
Taking note with async polyfills and syntax for a minute. I spent a fair amount of time actually writing the spec of my intent/goal after getting some thought and working things through in my head (varies slightly from old 2011 await): https://gist.github.com/bmeck/674e21f40fe6e9ce6304#file-close-but-no-cigar-sweet-js-L6 I can get really close with sweet.js (see gist), but as such I still have to use new when invoking the generator function which feels dirty in my mind. Perhaps if I did some crazy code transforms to test if the generator function was using await it would work. That would require me to wrap it similar to how task.js and all the other libraries IRC bombarded me with. I think it very strange that they all: 1. make a promise that will be returned (finalPromise) 2. call the generator and hook it up to the promise 3. don't appear to have a clean way to make the generator continue without resolving finalPromise and without forcing the generator to completion * bluebird's Promise.coroutine comes closeish but still needs to run the generator to completion It seems that every approach I am taking gets me slightly closer, but none are a clean way for a generator to iterate itself without some hacky argument passing and wrapping. PS. Sorry about the horrifying sweet.js macro, but it is functional enough in Chrome with experimental JS from what I tried out. On Fri, Jan 24, 2014 at 2:18 AM, David Herman dher...@mozilla.com wrote: On Jan 23, 2014, at 4:49 PM, Brendan Eich bren...@mozilla.com wrote: Domenic Denicola wrote: Task.js is still on JavaScript1.8, and is not ES6-compatible. It won't work with modern browsers, or with Regenerator. Fork and fix, should be easy. I expect a PR would be accepted in due course. SpiderMonkey seems to have ES6 generator support somewhat there (thanks to Andy Wingo), should be all there soon enough. Working on it lately, actually. And using regenerator for the tests (\o/)! Also drastically simplifying the library since the customizable scheduler stuff, while kind of neat, is probably less compelling than a minimal library. Down to under 150 lines, unminified with comments, and still shrinking... Dave ___ 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: Reason why generators do not have references to themselves?
It seems like this is largely a matter of personal aesthetics (feels dirty, hacky, etc.) but nothing is wrong or even hard functionally. Furthermore given the prevalence of code out there that uses such hacks without compunction, it seems that your aesthetics are not shared by most. Maybe the easiest path toward resolving this, um, problem?, is simply adjusting your preferences to recognize this kind of code for the beautiful code it is. On Jan 24, 2014, at 4:07, Bradley Meck bradley.m...@gmail.commailto:bradley.m...@gmail.com wrote: Taking note with async polyfills and syntax for a minute. I spent a fair amount of time actually writing the spec of my intent/goal after getting some thought and working things through in my head (varies slightly from old 2011 await): https://gist.github.com/bmeck/674e21f40fe6e9ce6304#file-close-but-no-cigar-sweet-js-L6 I can get really close with sweet.js (see gist), but as such I still have to use new when invoking the generator function which feels dirty in my mind. Perhaps if I did some crazy code transforms to test if the generator function was using await it would work. That would require me to wrap it similar to how task.js and all the other libraries IRC bombarded me with. I think it very strange that they all: 1. make a promise that will be returned (finalPromise) 2. call the generator and hook it up to the promise 3. don't appear to have a clean way to make the generator continue without resolving finalPromise and without forcing the generator to completion * bluebird's Promise.coroutine comes closeish but still needs to run the generator to completion It seems that every approach I am taking gets me slightly closer, but none are a clean way for a generator to iterate itself without some hacky argument passing and wrapping. PS. Sorry about the horrifying sweet.js macro, but it is functional enough in Chrome with experimental JS from what I tried out. On Fri, Jan 24, 2014 at 2:18 AM, David Herman dher...@mozilla.commailto:dher...@mozilla.com wrote: On Jan 23, 2014, at 4:49 PM, Brendan Eich bren...@mozilla.commailto:bren...@mozilla.com wrote: Domenic Denicola wrote: Task.js is still on JavaScript1.8, and is not ES6-compatible. It won't work with modern browsers, or with Regenerator. Fork and fix, should be easy. I expect a PR would be accepted in due course. SpiderMonkey seems to have ES6 generator support somewhat there (thanks to Andy Wingo), should be all there soon enough. Working on it lately, actually. And using regenerator for the tests (\o/)! Also drastically simplifying the library since the customizable scheduler stuff, while kind of neat, is probably less compelling than a minimal library. Down to under 150 lines, unminified with comments, and still shrinking... Dave ___ es-discuss mailing list es-discuss@mozilla.orgmailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.orgmailto: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
Fwd: Reason why generators do not have references to themselves?
Perhaps, but I am still a bit concerned functionality wise that I do not
have a clean way to force the `new generator()` piece of code to be inside
of the generator.
I cannot easily convert it akin to how new can be caught:
```
function* generatorFn() {
if (this instanceof generatorFn) {
return new generatorFn // does not work
}
}
```
Since it will be wrapped.
So I guess a throw trap is the only way:
```
function* generatorFn() {
if (this instanceof generatorFn) {
throw new Error(This must be called with new);
}
}
```
But even then we are not able to tell if the generator is in
standbyStartup or the currently active `generatorFn`. Does the lack of
being able to test that make sense?
On Fri, Jan 24, 2014 at 8:40 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
It seems like this is largely a matter of personal aesthetics (feels
dirty, hacky, etc.) but nothing is wrong or even hard functionally.
Furthermore given the prevalence of code out there that uses such hacks
without compunction, it seems that your aesthetics are not shared by most.
Maybe the easiest path toward resolving this, um, problem?, is simply
adjusting your preferences to recognize this kind of code for the beautiful
code it is.
On Jan 24, 2014, at 4:07, Bradley Meck bradley.m...@gmail.com wrote:
Taking note with async polyfills and syntax for a minute. I spent a
fair amount of time actually writing the spec of my intent/goal after
getting some thought and working things through in my head (varies slightly
from old 2011 await):
https://gist.github.com/bmeck/674e21f40fe6e9ce6304#file-close-but-no-cigar-sweet-js-L6
I can get really close with sweet.js (see gist), but as such I still
have to use new when invoking the generator function which feels dirty in
my mind.
Perhaps if I did some crazy code transforms to test if the generator
function was using await it would work. That would require me to wrap it
similar to how task.js and all the other libraries IRC bombarded me with. I
think it very strange that they all:
1. make a promise that will be returned (finalPromise)
2. call the generator and hook it up to the promise
3. don't appear to have a clean way to make the generator continue
without resolving finalPromise and without forcing the generator to
completion
* bluebird's Promise.coroutine comes closeish but still needs to run
the generator to completion
It seems that every approach I am taking gets me slightly closer, but
none are a clean way for a generator to iterate itself without some hacky
argument passing and wrapping.
PS. Sorry about the horrifying sweet.js macro, but it is functional
enough in Chrome with experimental JS from what I tried out.
On Fri, Jan 24, 2014 at 2:18 AM, David Herman dher...@mozilla.com wrote:
On Jan 23, 2014, at 4:49 PM, Brendan Eich bren...@mozilla.com wrote:
Domenic Denicola wrote:
Task.js is still on JavaScript1.8, and is not ES6-compatible. It
won't work with modern browsers, or with Regenerator.
Fork and fix, should be easy. I expect a PR would be accepted in due
course. SpiderMonkey seems to have ES6 generator support somewhat there
(thanks to Andy Wingo), should be all there soon enough.
Working on it lately, actually. And using regenerator for the tests
(\o/)! Also drastically simplifying the library since the customizable
scheduler stuff, while kind of neat, is probably less compelling than a
minimal library. Down to under 150 lines, unminified with comments, and
still shrinking...
Dave
___
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
detecting JS language mode for tools
For static language parsers there seems to be a bit of a dilemma with ES6 modules. I would appreciate a correct or hint. Here is my understanding: - standard scripts as we know them today will parse in the browser as loose code - scripts with the standard use strict will parse as strict with access to all ES6 goodness - scripts loaded as modules will parse as strict even without the use strict annotation. Is this true? If so, it seems like a tooling hazard and use strict on modules should at least be the encouraged convention. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: detecting JS language mode for tools
On Fri, Jan 24, 2014 at 8:48 AM, John Lenz concavel...@gmail.com wrote: For static language parsers there seems to be a bit of a dilemma with ES6 modules. I would appreciate a correct or hint. Here is my understanding: - standard scripts as we know them today will parse in the browser as loose code - scripts with the standard use strict will parse as strict with access to all ES6 goodness Loose code will also get all the ES6 goodness. 1JS and all that. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: detecting JS language mode for tools
You don't get let, function block scoping, yield or other incompatible constructs. (let and yield aren't a reserved word in ES5 loose) On Fri, Jan 24, 2014 at 8:49 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Fri, Jan 24, 2014 at 8:48 AM, John Lenz concavel...@gmail.com wrote: For static language parsers there seems to be a bit of a dilemma with ES6 modules. I would appreciate a correct or hint. Here is my understanding: - standard scripts as we know them today will parse in the browser as loose code - scripts with the standard use strict will parse as strict with access to all ES6 goodness Loose code will also get all the ES6 goodness. 1JS and all that. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: detecting JS language mode for tools
On Fri, Jan 24, 2014 at 8:49 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Fri, Jan 24, 2014 at 8:48 AM, John Lenz concavel...@gmail.com wrote: For static language parsers there seems to be a bit of a dilemma with ES6 modules. I would appreciate a correct or hint. Here is my understanding: - standard scripts as we know them today will parse in the browser as loose code - scripts with the standard use strict will parse as strict with access to all ES6 goodness Loose code will also get all the ES6 goodness. 1JS and all that. You can't use import or export (or module?) keywords in script. There are two parsing goals, one for script and one for module. So more like 2JS ;-) REPL is a dilemma: if you parse as module, then obtaining the last expression value is not simple. if you parse as a script, then common cut/paste fails on export/import statements. ~TJ ___ 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: detecting JS language mode for tools
I believe the conclusion with |let| was to identify let syntax: let foo(=*) is syntactically unambiguous, just a bit more work to identify. yield is only valid in generators (function*) so that gets reserved the moment you enter a generator definition —Oliver On Jan 24, 2014, at 9:11 AM, John Lenz concavel...@gmail.com wrote: You don't get let, function block scoping, yield or other incompatible constructs. (let and yield aren't a reserved word in ES5 loose) On Fri, Jan 24, 2014 at 8:49 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Fri, Jan 24, 2014 at 8:48 AM, John Lenz concavel...@gmail.com wrote: For static language parsers there seems to be a bit of a dilemma with ES6 modules. I would appreciate a correct or hint. Here is my understanding: - standard scripts as we know them today will parse in the browser as loose code - scripts with the standard use strict will parse as strict with access to all ES6 goodness Loose code will also get all the ES6 goodness. 1JS and all that. ~TJ ___ 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: detecting JS language mode for tools
On Fri, Jan 24, 2014 at 9:16 AM, John Barton johnjbar...@google.com wrote: On Fri, Jan 24, 2014 at 8:49 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Fri, Jan 24, 2014 at 8:48 AM, John Lenz concavel...@gmail.com wrote: For static language parsers there seems to be a bit of a dilemma with ES6 modules. I would appreciate a correct or hint. Here is my understanding: - standard scripts as we know them today will parse in the browser as loose code - scripts with the standard use strict will parse as strict with access to all ES6 goodness Loose code will also get all the ES6 goodness. 1JS and all that. You can't use import or export (or module?) keywords in script. There are two parsing goals, one for script and one for module. So more like 2JS ;-) You can't import from a script? How do you load the first module? That seemed like the natural migration strategy. REPL is a dilemma: if you parse as module, then obtaining the last expression value is not simple. if you parse as a script, then common cut/paste fails on export/import statements. My basic question remains. As a tool owner how do I know if what I'm looking at is intended to be a Module or a Script? ~TJ ___ 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: detecting JS language mode for tools
On Fri, Jan 24, 2014 at 9:17 AM, Oliver Hunt oli...@apple.com wrote: I believe the conclusion with |let| was to identify let syntax: let foo(=*) is syntactically unambiguous, just a bit more work to identify. yield is only valid in generators (function*) so that gets reserved the moment you enter a generator definition That is great, that only leave block scoped function declarations (and anything else I'm not aware of) —Oliver On Jan 24, 2014, at 9:11 AM, John Lenz concavel...@gmail.com wrote: You don't get let, function block scoping, yield or other incompatible constructs. (let and yield aren't a reserved word in ES5 loose) On Fri, Jan 24, 2014 at 8:49 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Fri, Jan 24, 2014 at 8:48 AM, John Lenz concavel...@gmail.com wrote: For static language parsers there seems to be a bit of a dilemma with ES6 modules. I would appreciate a correct or hint. Here is my understanding: - standard scripts as we know them today will parse in the browser as loose code - scripts with the standard use strict will parse as strict with access to all ES6 goodness Loose code will also get all the ES6 goodness. 1JS and all that. ~TJ ___ 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: detecting JS language mode for tools
Le 24/01/2014 18:26, John Lenz a écrit : REPL is a dilemma: if you parse as module, then obtaining the last expression value is not simple. if you parse as a script, then common cut/paste fails on export/import statements. My basic question remains. As a tool owner how do I know if what I'm looking at is intended to be a Module or a Script? How do you know if some code is intended for the browser or Node? How do you know some code is intended to be used in a WebWorker and not in the main thread? How do you know the code won't be concatenated a use strict when someone else uses it? The code itself lacks the context in which it's being loaded (hence very defensive patterns like UMD (Universal Module Definition)). If you want to be exhaustive, you'll have to make an assumption or make your tool smarter about the context. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: detecting JS language mode for tools
You don't get let, function block scoping, yield or other incompatible constructs. (let and yield aren't a reserved word in ES5 loose) It is true that there is some weirdness with let/const and block scoping in non-strict mode, but these issues can be sufficiently mitigated. IE11 has shipped let/const support and block-scoped functions with (mostly) backwards compatible semantics. For example, `let let = 1;` works in IE11 today outside of strict mode. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: detecting JS language mode for tools
On Fri, Jan 24, 2014 at 9:32 AM, David Bruant bruan...@gmail.com wrote: Le 24/01/2014 18:26, John Lenz a écrit : REPL is a dilemma: if you parse as module, then obtaining the last expression value is not simple. if you parse as a script, then common cut/paste fails on export/import statements. My basic question remains. As a tool owner how do I know if what I'm looking at is intended to be a Module or a Script? How do you know if some code is intended for the browser or Node? How do you know some code is intended to be used in a WebWorker and not in the main thread? These don't affect how the code is parsed or the behavior of the language itself. How do you know the code won't be concatenated a use strict when someone else uses it? This is an assembly issue and doesn't void intent.If it is true you won't be able import from a script, it is very reasonable to want to warn about this. The code itself lacks the context in which it's being loaded (hence very defensive patterns like UMD (Universal Module Definition)). If you want to be exhaustive, you'll have to make an assumption or make your tool smarter about the context. I want it to be smarter about the context, but smarter means knowing without being told. Having a different set of reserved words (between loose and strict mode) means this is a parser issue. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: detecting JS language mode for tools
If we are asking questions: why two parse goals? Why not allow import in Script and let it act like the code was wrapped in Loader.import() and allow export then just ignore it? The semantics of 'var' would be changed by appearance of 'import' just like the semantics of code changes with the appearance of 'use strict'. On Fri, Jan 24, 2014 at 9:32 AM, David Bruant bruan...@gmail.com wrote: Le 24/01/2014 18:26, John Lenz a écrit : REPL is a dilemma: if you parse as module, then obtaining the last expression value is not simple. if you parse as a script, then common cut/paste fails on export/import statements. My basic question remains. As a tool owner how do I know if what I'm looking at is intended to be a Module or a Script? How do you know if some code is intended for the browser or Node? How do you know some code is intended to be used in a WebWorker and not in the main thread? How do you know the code won't be concatenated a use strict when someone else uses it? The code itself lacks the context in which it's being loaded (hence very defensive patterns like UMD (Universal Module Definition)). If you want to be exhaustive, you'll have to make an assumption or make your tool smarter about the context. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: detecting JS language mode for tools
As long as you can import from a script in some fashion: Loader.import works for me. I'm a little concerned that import/export will need to work as a use strict On Fri, Jan 24, 2014 at 9:55 AM, John Barton johnjbar...@google.com wrote: If we are asking questions: why two parse goals? Why not allow import in Script and let it act like the code was wrapped in Loader.import() and allow export then just ignore it? The semantics of 'var' would be changed by appearance of 'import' just like the semantics of code changes with the appearance of 'use strict'. On Fri, Jan 24, 2014 at 9:32 AM, David Bruant bruan...@gmail.com wrote: Le 24/01/2014 18:26, John Lenz a écrit : REPL is a dilemma: if you parse as module, then obtaining the last expression value is not simple. if you parse as a script, then common cut/paste fails on export/import statements. My basic question remains. As a tool owner how do I know if what I'm looking at is intended to be a Module or a Script? How do you know if some code is intended for the browser or Node? How do you know some code is intended to be used in a WebWorker and not in the main thread? How do you know the code won't be concatenated a use strict when someone else uses it? The code itself lacks the context in which it's being loaded (hence very defensive patterns like UMD (Universal Module Definition)). If you want to be exhaustive, you'll have to make an assumption or make your tool smarter about the context. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: detecting JS language mode for tools
On Jan 24, 2014, at 9:32 AM, David Bruant wrote: Le 24/01/2014 18:26, John Lenz a écrit : REPL is a dilemma: if you parse as module, then obtaining the last expression value is not simple. if you parse as a script, then common cut/paste fails on export/import statements. My basic question remains. As a tool owner how do I know if what I'm looking at is intended to be a Module or a Script? How do you know if some code is intended for the browser or Node? How do you know some code is intended to be used in a WebWorker and not in the main thread? How do you know the code won't be concatenated a use strict when someone else uses it? The code itself lacks the context in which it's being loaded (hence very defensive patterns like UMD (Universal Module Definition)). If you want to be exhaustive, you'll have to make an assumption or make your tool smarter about the context. I've had some discussion with Dave Herman about this and I think there is a plausible way to handle it. I'm not sure if Dave would totally agree with 100% of the following but I think it is close to what seemed to make sense in our discussions. 1) there are some very good technical reasons for having two syntactic goals (script and module) corresponding to the two semantics. 2) A module with no imports and no exports is essentially a new form of top level code that is always strict mode and but has its own file level scope. 3) In browsers, html syntax (new attribute on script tag, etc.) can be used to distinguish the two. Dave is working on this. 4) but there are other situations where the intended syntactic goal of a source file need to be identifiable. For example, when listing source files on a command-line invocations of a JavaScript engine or tool 5) Humans when reading or managing code files also need to know which kind of JS source file they are dealing with. 6) typically we use file extensions to make distinctions of this sort. 7) Hence, it probably makes sense to promote a convention of using a new file extension for ES6 source files that are intended to be parsed with the modules goal. .jsm, or mjs, or something similar that is appropriately suggestive and isn't already widely used as an extension. Allen___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: detecting JS language mode for tools
7) Hence, it probably makes sense to promote a convention of using a new file extension for ES6 source files that are intended to be parsed with the modules goal. .jsm, or mjs, or something similar that is appropriately suggestive and isn't already widely used as an extension. Allen, I'm so glad you brought this option up! I've had it in the back of my mind for a good long while but I've always been hesitant to suggest it. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: detecting JS language mode for tools
I should have also included: 2A) Hopefully, overtime, the old script syntactic goal will fade from use, and the module goal will become the norm for new code. On Jan 24, 2014, at 11:38 AM, Allen Wirfs-Brock wrote: On Jan 24, 2014, at 9:32 AM, David Bruant wrote: Le 24/01/2014 18:26, John Lenz a écrit : REPL is a dilemma: if you parse as module, then obtaining the last expression value is not simple. if you parse as a script, then common cut/paste fails on export/import statements. My basic question remains. As a tool owner how do I know if what I'm looking at is intended to be a Module or a Script? How do you know if some code is intended for the browser or Node? How do you know some code is intended to be used in a WebWorker and not in the main thread? How do you know the code won't be concatenated a use strict when someone else uses it? The code itself lacks the context in which it's being loaded (hence very defensive patterns like UMD (Universal Module Definition)). If you want to be exhaustive, you'll have to make an assumption or make your tool smarter about the context. I've had some discussion with Dave Herman about this and I think there is a plausible way to handle it. I'm not sure if Dave would totally agree with 100% of the following but I think it is close to what seemed to make sense in our discussions. 1) there are some very good technical reasons for having two syntactic goals (script and module) corresponding to the two semantics. 2) A module with no imports and no exports is essentially a new form of top level code that is always strict mode and but has its own file level scope. 3) In browsers, html syntax (new attribute on script tag, etc.) can be used to distinguish the two. Dave is working on this. 4) but there are other situations where the intended syntactic goal of a source file need to be identifiable. For example, when listing source files on a command-line invocations of a JavaScript engine or tool 5) Humans when reading or managing code files also need to know which kind of JS source file they are dealing with. 6) typically we use file extensions to make distinctions of this sort. 7) Hence, it probably makes sense to promote a convention of using a new file extension for ES6 source files that are intended to be parsed with the modules goal. .jsm, or mjs, or something similar that is appropriately suggestive and isn't already widely used as an extension. Allen ___ 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: detecting JS language mode for tools
Assuming the current system for a moment, and discussing only conventions: It is true that a use strict at the top of every *.js file does have the virtue of making it clear, both to tools and humans, that the remainder is strict code, even in one doesn't know if the file is to be loaded as a module or a script. Historically, we've recommended against a bare use strict at the top of script files http://wiki.ecmascript.org/doku.php?id=conventions:avoid_strictness_contagion , in order to avoid the concatenation hazard. Instead, we recommend that script files have an outer strict IIFE. This still seems sensible when there's genuine ambiguity about whether it is a module or a script. OTOH, if the author knows it is a module and simply wants to disambiguate to tools that it is strict, then the author knows there's no concatenation hazard and a bare use strict at the top would be fine. And, of course, if there are any export or import statements in there, then it cannot be a script, and it cannot be contained in an IIFE. Btw, the conventional name for the opposite of strict is sloppy rather than loose. On Fri, Jan 24, 2014 at 8:48 AM, John Lenz concavel...@gmail.com wrote: For static language parsers there seems to be a bit of a dilemma with ES6 modules. I would appreciate a correct or hint. Here is my understanding: - standard scripts as we know them today will parse in the browser as loose code - scripts with the standard use strict will parse as strict with access to all ES6 goodness - scripts loaded as modules will parse as strict even without the use strict annotation. Is this true? If so, it seems like a tooling hazard and use strict on modules should at least be the encouraged convention. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: detecting JS language mode for tools
On Fri, Jan 24, 2014 at 12:17 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: I should have also included: 2A) Hopefully, overtime, the old script syntactic goal will fade from use, and the module goal will become the norm for new code. Now here is a reason, finally, for all the extra complexity the two goals cause. If we want to kill script, let's not stab it with a dull pencil. Let's make Loader and System be modules, not globals. Then you cannot load modules with script, only with module. On Jan 24, 2014, at 11:38 AM, Allen Wirfs-Brock wrote: On Jan 24, 2014, at 9:32 AM, David Bruant wrote: Le 24/01/2014 18:26, John Lenz a écrit : REPL is a dilemma: if you parse as module, then obtaining the last expression value is not simple. if you parse as a script, then common cut/paste fails on export/import statements. My basic question remains. As a tool owner how do I know if what I'm looking at is intended to be a Module or a Script? How do you know if some code is intended for the browser or Node? How do you know some code is intended to be used in a WebWorker and not in the main thread? How do you know the code won't be concatenated a use strict when someone else uses it? The code itself lacks the context in which it's being loaded (hence very defensive patterns like UMD (Universal Module Definition)). If you want to be exhaustive, you'll have to make an assumption or make your tool smarter about the context. I've had some discussion with Dave Herman about this and I think there is a plausible way to handle it. I'm not sure if Dave would totally agree with 100% of the following but I think it is close to what seemed to make sense in our discussions. 1) there are some very good technical reasons for having two syntactic goals (script and module) corresponding to the two semantics. 2) A module with no imports and no exports is essentially a new form of top level code that is always strict mode and but has its own file level scope. 3) In browsers, html syntax (new attribute on script tag, etc.) can be used to distinguish the two. Dave is working on this. 4) but there are other situations where the intended syntactic goal of a source file need to be identifiable. For example, when listing source files on a command-line invocations of a JavaScript engine or tool 5) Humans when reading or managing code files also need to know which kind of JS source file they are dealing with. 6) typically we use file extensions to make distinctions of this sort. 7) Hence, it probably makes sense to promote a convention of using a new file extension for ES6 source files that are intended to be parsed with the modules goal. .jsm, or mjs, or something similar that is appropriately suggestive and isn't already widely used as an extension. Allen ___ 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: detecting JS language mode for tools
I'm perfectly happy with convention of some kind: a) a file extension b) a comment on the first line of the file: // module mymodule c) a use strict style annotation that is just documentation: module mymodule; The key thing in my mind is that TC39 pick something and encourage it. On Fri, Jan 24, 2014 at 11:38 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Jan 24, 2014, at 9:32 AM, David Bruant wrote: Le 24/01/2014 18:26, John Lenz a écrit : REPL is a dilemma: if you parse as module, then obtaining the last expression value is not simple. if you parse as a script, then common cut/paste fails on export/import statements. My basic question remains. As a tool owner how do I know if what I'm looking at is intended to be a Module or a Script? How do you know if some code is intended for the browser or Node? How do you know some code is intended to be used in a WebWorker and not in the main thread? How do you know the code won't be concatenated a use strict when someone else uses it? The code itself lacks the context in which it's being loaded (hence very defensive patterns like UMD (Universal Module Definition)). If you want to be exhaustive, you'll have to make an assumption or make your tool smarter about the context. I've had some discussion with Dave Herman about this and I think there is a plausible way to handle it. I'm not sure if Dave would totally agree with 100% of the following but I think it is close to what seemed to make sense in our discussions. 1) there are some very good technical reasons for having two syntactic goals (script and module) corresponding to the two semantics. 2) A module with no imports and no exports is essentially a new form of top level code that is always strict mode and but has its own file level scope. 3) In browsers, html syntax (new attribute on script tag, etc.) can be used to distinguish the two. Dave is working on this. 4) but there are other situations where the intended syntactic goal of a source file need to be identifiable. For example, when listing source files on a command-line invocations of a JavaScript engine or tool 5) Humans when reading or managing code files also need to know which kind of JS source file they are dealing with. 6) typically we use file extensions to make distinctions of this sort. 7) Hence, it probably makes sense to promote a convention of using a new file extension for ES6 source files that are intended to be parsed with the modules goal. .jsm, or mjs, or something similar that is appropriately suggestive and isn't already widely used as an extension. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: detecting JS language mode for tools
I'm perfectly happy with convention of some kind: a) a file extension b) a comment on the first line of the file: // module mymodule c) a use strict style annotation that is just documentation: module mymodule; One of the nicest things about the current modules syntax is that it avoids annoying boilerplate. Let's have none of that : ) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Fwd: Reason why generators do not have references to themselves?
Bradley Meck wrote: Perhaps, but I am still a bit concerned functionality wise that I do not have a clean way to force the `new generator()` piece of code to be inside of the generator. I think you've gone down a bad path. Even without task.js, couldn't you put the promises .then'ing in the generator schedule, instead of requiring each generator to open-code the .then/.catches, which in turn requires you to have a ref to the generator? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: detecting JS language mode for tools
John Barton wrote:
On Fri, Jan 24, 2014 at 12:17 PM, Allen Wirfs-Brock
al...@wirfs-brock.com mailto:al...@wirfs-brock.com wrote:
I should have also included:
2A) Hopefully, overtime, the old script syntactic goal will fade
from use, and the module goal will become the norm for new code.
Now here is a reason, finally, for all the extra complexity the two
goals cause.
If we want to kill script, let's not stab it with a dull pencil. Let's
make Loader and System be modules, not globals. Then you cannot load
modules with script, only with module.
We are not killing script Dream on!
Introducing a new HTML element with implicit CDATA content model will
require the old
module
!-- hide script here
if (a b) { console.log(\/script haha); }
--
/module
hacks. This won't do anything (even render the HTML-commented-out
fallback content) in old browsers, which will make it hard to work in
both new and old.
Using script with a new attribute has several advantages, in contrast:
1. No need for the return of the HTML comment-hiding hack I invented in
Netscape 2 to avoid inline script content showing as fallback in
pre-Netscape-2 browsers.
2. Old browsers ignore the new attribute will process the content, which
could be written to work both ways.
But mainly: no way to kill script. Amending above words: do not dream
on, wake up!
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: transpiling ES6 generator functions to ES5: what next?
David Bruant wrote: Hi Ben, Sorry for the very late response. This is quite an interesting work, thanks for sharing! I'm particularly interested in your test suite [1] which is impressive. This is making me realize that generators are fully compilable (efficiently from what I can see) into ES5 and makes me wonder if the current generators specificities are worth it. Very specifically, do we really need Generator.prototype [ @@toStringTag ] === Generator ? From an author point of view, I don't really see in which situation this information could matter. As a comparison, functions generated after the class syntax do not have an @@toStringTag to Class. Generators would just be sugar to write iterators (+ .throw) The answer is that class constructor is a Function instance, not a ClassFunction instance, because classes are mostly sugar for the prototypal pattern, whereas generators do *not* desugar in any translating-not-compiling sense. Matthias Felleisen wrote a paper, On the Expressive Power of Programming Languages, that gets at the difference between compilation in general and translation or desugaring. You say generators are sugar to write iterators (+ .throw), but my understanding per Felleisen is that's an abuse of sugar. Regenerator is a compiler, not a translator of like-to-like-expressiveness languages. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
