“Arrow is not a replacement for all functions that want lexical this”
Source: David Herman, https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-11/nov-20.md Can someone elaborate? I don’t see an alternative. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Async functions?
In the most recent meeting notes, “async functions” were mentioned [1] (keyword: `function!`). Is there a proposal somewhere? Is it the following one? http://wiki.ecmascript.org/doku.php?id=strawman:deferred_functions [1] https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-11/nov-20.md#410-generator-arrow-function-syntax Thanks! Axel -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Using const to remove debug code? Is there something stopping implementers from doing this?
Lately I've been writing very processor heavy Javascript. I feel like it could
benefit a lot from having a syntax feature for removing debug statements.
Obviously JS is interpreted and not compiled, so I'm not sure if this sounds
completely unrealistic, but it has some very useful scenarios.
I like to write verbose type checking for functions to check ranges and throw
exceptions if invalid input is detected. The issue is in a production
environment (especially with games) the code executes too slowly with all the
extra branches. It would be nice if there was a simple syntax to treat code as
if it's commented out when a flag is set. In some languages this is done with
preprocessor statements like:
#if debug
console.log(Debug Mode);
#else
console.log(Release Mode);
#endif
The alternative is simply:
const debug = false;
if (debug)
{
// Tons of type checking
}
What I'd expect would be possible for an implementer is to get to the constant
and evaluate the branch and remove the whole statement before running it
through the JIT. This would allow a very standard way to turn on and off pieces
of code. An example program:
// Debug Off Control
{
console.time(benchmark control);
for (var i = 0; i 1000; ++i)
{
}
console.timeEnd(benchmark control);
}
// Debug Off
{
const debugOff = false;
var debugOffCounter = 0;
console.time(benchmark debug off);
for (var i = 0; i 1000; ++i)
{
if (debugOff)
{
debugOffCounter++;
}
}
console.timeEnd(benchmark debug off);
}
// Debug On
{
const debugOn = true;
var debugOnCounter = 0;
console.time(benchmark debug on);
for (var i = 0; i 1000; ++i)
{
if (debugOn)
{
debugOnCounter++;
}
}
console.timeEnd(benchmark debug on);
}
http://jsfiddle.net/9LCra/
On the latest Firefox there's a 11 ms difference between the control and using
a constant in the if. In chrome there's a 23 ms difference. Is there anything
stopping an implementer from evaluating the constant and making the control and
debug off identical in performance?
I kind of want this to be like a standard goto technique that's expected to
work since I believe right now the alternative is to simply create two files or
remove anything that might slow things down.
I decided to post here first in case there's a fundamental reason that such a
use case would be impossible or if an alternative was in the works that would
fit this goal.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Using const to remove debug code? Is there something stopping implementers from doing this?
Le 28/11/2013 09:59, Brandon Andrews a écrit : Lately I've been writing very processor heavy Javascript. I feel like it could benefit a lot from having a syntax feature for removing debug statements. Obviously JS is interpreted and not compiled, so I'm not sure if this sounds completely unrealistic, but it has some very useful scenarios. I like to write verbose type checking for functions to check ranges and throw exceptions if invalid input is detected. The issue is in a production environment (especially with games) the code executes too slowly with all the extra branches. It would be nice if there was a simple syntax to treat code as if it's commented out when a flag is set. Does this need to be part of JavaScript (and be implemented in web browsers)? From what I understand, what you're describing is purely a development time concern and not a (production) runtime concern, so I feel the solution should be found in better development tooling. Good news! Olov Lassus already worked on something like this! http://blog.lassus.se/2011/03/c-style-assertions-in-javascript-via.html https://www.youtube.com/watch?v=yk6t4kRN53w I haven't looked at it too much, but it might be possible to do assertions (that run in dev, but not in prod) with Sweet.js [1] macros. Potentially that's something that could be part of TypeScript too (I haven't seen an issue on this topic or in the roadmap, but maybe that's an addition they'd be open to do?). JavaScript isn't compiled, but we can build tools that do compile to JS without requiring support from the browser. David [1] http://sweetjs.org/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Async functions?
http://wiki.ecmascript.org/doku.php?id=strawman:async_functions cheers, MarkM On Nov 28, 2013 12:34 AM, Axel Rauschmayer a...@rauschma.de wrote: In the most recent meeting notes, “async functions” were mentioned [1] (keyword: `function!`). Is there a proposal somewhere? Is it the following one? http://wiki.ecmascript.org/doku.php?id=strawman:deferred_functions [1] https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-11/nov-20.md#410-generator-arrow-function-syntax Thanks! Axel -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.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: Async functions?
Thanks! But I don’t see `function!`, anywhere. On Nov 28, 2013, at 16:10 , Mark S. Miller erig...@google.com wrote: http://wiki.ecmascript.org/doku.php?id=strawman:async_functions cheers, MarkM On Nov 28, 2013 12:34 AM, Axel Rauschmayer a...@rauschma.de wrote: In the most recent meeting notes, “async functions” were mentioned [1] (keyword: `function!`). Is there a proposal somewhere? Is it the following one? http://wiki.ecmascript.org/doku.php?id=strawman:deferred_functions [1] https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-11/nov-20.md#410-generator-arrow-function-syntax -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Using const to remove debug code? Is there something stopping implementers from doing this?
Both Closure Compiler and UglifyJS has something called defines which allow you to override the value of a variable using a command line parameter. Combining this with their dead code removal and you have a preprocessor tool similar to #ifdefs. https://github.com/mishoo/UglifyJS2#conditional-compilation https://developers.google.com/closure/compiler/docs/js-for-compiler (search for @define) On Nov 28, 2013 5:25 AM, David Bruant bruan...@gmail.com wrote: Le 28/11/2013 09:59, Brandon Andrews a écrit : Lately I've been writing very processor heavy Javascript. I feel like it could benefit a lot from having a syntax feature for removing debug statements. Obviously JS is interpreted and not compiled, so I'm not sure if this sounds completely unrealistic, but it has some very useful scenarios. I like to write verbose type checking for functions to check ranges and throw exceptions if invalid input is detected. The issue is in a production environment (especially with games) the code executes too slowly with all the extra branches. It would be nice if there was a simple syntax to treat code as if it's commented out when a flag is set. Does this need to be part of JavaScript (and be implemented in web browsers)? From what I understand, what you're describing is purely a development time concern and not a (production) runtime concern, so I feel the solution should be found in better development tooling. Good news! Olov Lassus already worked on something like this! http://blog.lassus.se/2011/03/c-style-assertions-in-javascript-via.html https://www.youtube.com/watch?v=yk6t4kRN53w I haven't looked at it too much, but it might be possible to do assertions (that run in dev, but not in prod) with Sweet.js [1] macros. Potentially that's something that could be part of TypeScript too (I haven't seen an issue on this topic or in the roadmap, but maybe that's an addition they'd be open to do?). JavaScript isn't compiled, but we can build tools that do compile to JS without requiring support from the browser. David [1] http://sweetjs.org/ ___ 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: Using const to remove debug code? Is there something stopping implementers from doing this?
On Nov 28, 2013, at 12:59 AM, Brandon Andrews warcraftthre...@sbcglobal.net
wrote:
Lately I've been writing very processor heavy Javascript. I feel like it
could benefit a lot from having a syntax feature for removing debug
statements. Obviously JS is interpreted and not compiled,
so I'm not sure if this sounds completely unrealistic, but it has some very
useful scenarios.
I like to write verbose type checking for functions to check ranges and throw
exceptions if invalid input is detected. The issue is in a production
environment (especially with games) the code executes too slowly with all the
extra branches. It would be nice if there was a simple syntax to treat code
as if it's commented out when a flag is set. In some languages this is done
with preprocessor statements like:
#if debug
console.log(Debug Mode);
#else
console.log(Release Mode);
#endif
The alternative is simply:
const debug = false;
if (debug)
{
// Tons of type checking
}
This falls firmly within the realm of things that a JS engine should be able to
infer automatically and so using const isn't useful from a performance
standpoint.
You will get the same effect from var debug = false.
This will probably already get optimized the way you want by optimizing JITs.
If it isn't then you should file bugs against those JITs. No need to change the
language.
Here's why var is good enough provided that you do the var debug = false
thing at the top of the function:
- it's obvious that the variable is only assigned once and that it's assigned
before any use.
- var is one of the few JS constructs that lends itself naturally to static
reasoning, unless you use eval or with. What this means is that every use of
debug can be folded to its One True Value (I.e. false in this case) unless
you use it from within a with or you have an eval statement in the same scope
(how well a JS engine handles eval statements varies greatly so don't use eval
if you want performance).
All of the examples you give will work properly if you say var instead of
const.
Here's an example of eval being a hater:
function foo() {
var debug = false;
eval(blah); // did this change debug or not? It's fair to assume that a JS
engine will conservatively assume that debug gets changed by this.
if (debug) console.log(things);
}
So, I guess we could concede that const would be useful if you had such evals,
but then again, if you have such evals then an if (debug) statement not
getting folded is the least of your performance worries. Eval is kinda slow. ;-)
Now, some insight into why you might currently be seeing a performance
difference with or without the if (debug) statements:
- if you're defining debug in an outer function and using it in a nested
function. Even though that's easy to optimize some engines may fail to do it.
File bugs against those engines.
- if an engine is seeing that blob of dead code and allowing it to affect
inlining heuristics. This is a classic inlined bug; heck even C compiler people
still have to fix performance bugs due to stuff like this. Again, file bugs
against engines.
If you can come up with an example program that runs faster without an if
(debug) than with it, then file a bug against the relevant engines with that
program attached.
What I'd expect would be possible for an implementer is to get to the
constant and evaluate the branch and remove the whole statement before
running it through the JIT. This would allow a very standard way to turn on
and off pieces of code. An example program:
// Debug Off Control
{
console.time(benchmark control);
for (var i = 0; i 1000; ++i)
{
}
console.timeEnd(benchmark control);
}
// Debug Off
{
const debugOff = false;
var debugOffCounter = 0;
console.time(benchmark debug off);
for (var i = 0; i 1000; ++i)
{
if (debugOff)
{
debugOffCounter++;
}
}
console.timeEnd(benchmark debug off);
}
// Debug On
{
const debugOn = true;
var debugOnCounter = 0;
console.time(benchmark debug on);
for (var i = 0; i 1000; ++i)
{
if (debugOn)
{
debugOnCounter++;
}
}
console.timeEnd(benchmark debug on);
}
http://jsfiddle.net/9LCra/
On the latest Firefox there's a 11 ms difference between the control and
using a constant in the if. In chrome there's a 23 ms difference. Is there
anything stopping an implementer from evaluating the constant and making the
control and debug off identical in performance?
I kind of want this to be like a standard goto technique that's expected to
work since I believe right now the alternative is to simply create two files
or remove anything that might slow things down.
I decided to post here first in case there's a fundamental reason that such a
use case would be impossible or if an
Re: [Json] Consensus on JSON-text (WAS: JSON: remove gap between Ecma-404 and IETF draft)
On Nov 27, 2013, at 7:29 PM, Paul Hoffman wrote: no hat On Nov 27, 2013, at 5:00 PM, Alex Russell slightly...@google.com wrote: Will you also be citing ECMA-404 normatively to avoid this sort of divergence in the future? If you believe that ECMA-404 will change in the future, that would indicate that ECMA might break interoperability with current implementations, even for what they perceive as good reasons. In general, the IETF tries not to have its long-lived standards normatively latch on to moving targets for this very reason. Even when other SDOs have assured us that they will not make backwards-incompatible changes, they have done so anyway (cue the Klensin-esqe theme music...), and that has caused serious interoperability problems for the IETF specs. Stability of ECMA-404 should not be a concern. As far as I can observe TC39 has absolutely no interest in every changing or extending the JSON grammar. I'm confident TC39 would record that as a statement of policy if asked. In fact, the reason TC39 chose to issue ECMA-404 was because there was concern that the JSON WG was on a path to modify and possibly extend JSON syntax. The only sort of changes to ECAM-404 I ever expect to see would be technical corrections to errors found in the current specification language or the addition of informative material to help clarify understanding of the specification. For example, if there was sufficient public interest we might consider adding an informative Annex that restates the grammar using ABNF notation. The JSON syntax has its roots in the ECMAScript syntax but is not at all linked to the ECMAScript syntax. The ECMAScript object and array literal constructs were the inspiration for JSON. But even in the beginning, the JSON syntax was only a subset set of the full syntax of those ECMAScript language features. ECMAScript object literal syntax has been significantly extended in both the ECMA-262 5th Edition(2009) and the forthcoming 6th Edition. But those extensions have and will not ever be added to the JSON syntax defined in ECMA-404. Allen Wirfs-Brock ECMA-262 Project Editor ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Using const to remove debug code? Is there something stopping implementers from doing this?
On 11/28/13 11:41 AM, Filip Pizlo wrote: Here's why var is good enough provided that you do the var debug = false thing at the top of the function: I would think it would be done at window scope, or in some module scope, not at the top of every function, no? -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generators Grammar and Yield
function*(a = yield/b/g) {
a = yield/b/g;
}
Why allow yield as an identifier in parameter defaults of generators?
Wouldn't it be simpler just to disallow there as well?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Generators Grammar and Yield
Kevin Smith wrote:
function*(a = yield/b/g) {
a = yield/b/g;
}
Why allow yield as an identifier in parameter defaults of generators?
Wouldn't it be simpler just to disallow there as well?
When proposing an irregularity, you need a better reason than why allow?
Parameter default values pave a cowpath of the form
function f(a) {
a = a || default_a;
...
}
(yes, falsy test and all).
The new form does not desugar that way, of course. But defaults are
evaluated on each activation (contrast with Python, the mutable value
default shared singleton side-channel). So why shouldn't yield in a
default work? There could be a reason, but we don't have it yet.
Allen may have a thought.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Using const to remove debug code? Is there something stopping implementers from doing this?
On Nov 28, 2013, at 9:51 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/28/13 11:41 AM, Filip Pizlo wrote: Here's why var is good enough provided that you do the var debug = false thing at the top of the function: I would think it would be done at window scope, or in some module scope, not at the top of every function, no? Yes. As I pointed out later in that mail, having such an implicit constant defined in an outer function and used in a nested function should be fine but some engines may not optimize it yet. And I suggested that if you find examples of this not working right you should file bugs against the engines. But it turns out that if it's done at global scope then constant-inferring the variable is even easier than if it was local, so that kind of idiom definitely shouldn't require language help. -Filip -Boris ___ 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: Generators Grammar and Yield
On Nov 28, 2013, at 10:40 AM, Brendan Eich wrote:
Kevin Smith wrote:
function*(a = yield/b/g) {
a = yield/b/g;
}
Why allow yield as an identifier in parameter defaults of generators?
Wouldn't it be simpler just to disallow there as well?
When proposing an irregularity, you need a better reason than why allow?
Parameter default values pave a cowpath of the form
function f(a) {
a = a || default_a;
...
}
(yes, falsy test and all).
The new form does not desugar that way, of course. But defaults are evaluated
on each activation (contrast with Python, the mutable value default shared
singleton side-channel). So why shouldn't yield in a default work? There
could be a reason, but we don't have it yet.
Allen may have a thought.
'yield' is already disallowed in generator function default initializer
expressions (although I was reviewing the latest spec. revision yesterday and
there may still be still bugs I have to fix in that regard).
The reason it isn't allowed is that the generator object is not yet
instantiated and active at the point where a default value initializer would be
evaluated. (note you yield from a invocation on the generator object, not the
generator function that creates a generator object) .
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Generators Grammar and Yield
On Nov 28, 2013, at 11:24 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: The reason it isn't allowed is that the generator object is not yet instantiated and active at the point where a default value initializer would be evaluated. But just to be clear, defaults are evaluated per generator function invocation. Right? This is a fine reason for a static error on yield in parameter default, but, but to hammer on the virtue of function*, it still does not help with parsing. Good old * after function does. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generators Grammar and Yield
On Nov 28, 2013, at 11:47 AM, Brendan Eich wrote: On Nov 28, 2013, at 11:24 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: The reason it isn't allowed is that the generator object is not yet instantiated and active at the point where a default value initializer would be evaluated. But just to be clear, defaults are evaluated per generator function invocation. Right? right, but before the implicit yield at the top of the function body This is a fine reason for a static error on yield in parameter default, but, but to hammer on the virtue of function*, it still does not help with parsing. Good old * after function does. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generators Grammar and Yield
'yield' is already disallowed in generator function default initializer expressions (although I was reviewing the latest spec. revision yesterday and there may still be still bugs I have to fix in that regard). The reason it isn't allowed is that the generator object is not yet instantiated and active at the point where a default value initializer would be evaluated. (note you yield from a invocation on the generator object, not the generator function that creates a generator object) . Yes, 'yield' the operator is disallowed in parameter default expressions. But what about 'yield' the identifier? My current reading of the spec is that it _is_ allowed, but I could be misreading. It seems more natural to me to disallow 'yield' the identifier in the whole generator (formal parameters and body, both). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
