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.
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):
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
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) {
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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,
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
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
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
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
26 matches
Mail list logo
