Re: [syntax] arrow function notation is too greedy
On Thu, Jul 11, 2013 at 5:08 PM, Brendan Eich bren...@mozilla.com wrote: Very messy, and primordial JS (the Mocha interpreter) violated ECMA-262 Edition 1 on order of evaluation, e.g., o[x] = ++x where the RHS ++x must be evaluated *after* the Reference o[x] is evaluated. Fixing this prior to compiling to a parse tree required code buffering and reordering, just as the for loops (both of 'em) can. Again, this goes back to the dawn of JS. We're not making it any worse. I don't see finite lookahead helping in general for any of these cases, BTW. /be Compiling this arr[x] = ++x; does not require complete AST support as far as I can tell. Consider this: Some hypothetical bytecode: PUSH arr; PUSH x; -- RHS code - VAL in accumulator register -- SETVI; // stack[TOP-1] - arr // stack[TOP] - x, index, initial value of x // accum - x, final RHS value, x after increment DROP2; // accum here contains x value after increment - result // of the assignment expression. So that can be compiled to stack machine strictly in order it is defined. Or do you mean something else here? -- Andrew Fedoniouk. http://terrainformatica.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [proposal] Function calls, syntax sugar
I like the idea, maybe we could do the following:
foo(posArg1, posArg2, name1: x, name2: y)
as syntactic sugar for:
foo(posArg1, posArg2, { name1: x, name2: y })
Axel
On Jul 12, 2013, at 6:22 , Andrew Fedoniouk n...@terrainformatica.com wrote:
Quite often I see constructions like this:
foo({one:1,two:2});
so call of function with single parameter - object literal.
Idiom named Poor man named arguments passing
Idea is to extend existing JS/ES syntax calls to support
simple form of the call above:
foo {one:1,two:2 };
Semi-formally that syntax looks like:
function-call:
name-token '(' parameter-list ')' // existing form
name-token object-literal // proposal
This syntax extension will not break correct pre-ES6 code
as far as I can tell. But I am not sure about new ES6 arrivals.
In fact we can add even more generic form of function call:
foo 1,2,three;
that is an equivalent of foo(1,2,three);
In this case grammar may look like:
function-call:
name-token '(' parameter-list ')' // existing form
name-token parameter-list // proposal
Where parameter-list is comma ',' separated list of expressions.
Just to reduce that bracketing noise in syntax.
--
Andrew Fedoniouk.
http://terrainformatica.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
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: [proposal] Function calls, syntax sugar
On Fri, Jul 12, 2013 at 12:22 AM, Andrew Fedoniouk
n...@terrainformatica.com wrote:
Quite often I see constructions like this:
foo({one:1,two:2});
so call of function with single parameter - object literal.
Idiom named Poor man named arguments passing
Idea is to extend existing JS/ES syntax calls to support
simple form of the call above:
foo {one:1,two:2 };
Semi-formally that syntax looks like:
function-call:
name-token '(' parameter-list ')' // existing form
name-token object-literal // proposal
Given:
function foo(){ return 1; }
This is a valid function call:
foo
()
// 1;
But this is valid, too (though, not a function call):
foo -- identifier
{} -- empty block
// function foo() { return 1; }
Also, I could be wrong, but wouldn't there need to be a way to disambiguate
UnaryExpression?
typeof foo { one: 1, two: 2 }
Maybe this is not an issue, or easily dealt with?
This syntax extension will not break correct pre-ES6 code
as far as I can tell. But I am not sure about new ES6 arrivals.
In fact we can add even more generic form of function call:
foo 1,2,three;
The equivalent to:
foo(1, 2, bar(a, b))
is...
foo 1, 2, bar a, b
?
CoffeeScript has this problem, too.
Rick
that is an equivalent of foo(1,2,three);
In this case grammar may look like:
function-call:
name-token '(' parameter-list ')' // existing form
name-token parameter-list // proposal
Where parameter-list is comma ',' separated list of expressions.
Just to reduce that bracketing noise in syntax.
--
Andrew Fedoniouk.
http://terrainformatica.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: [proposal] Function calls, syntax sugar
On Fri, Jul 12, 2013 at 12:22 AM, Andrew Fedoniouk
n...@terrainformatica.com wrote:
Quite often I see constructions like this:
foo({one:1,two:2});
so call of function with single parameter - object literal.
Idiom named Poor man named arguments passing
Idea is to extend existing JS/ES syntax calls to support
simple form of the call above:
foo {one:1,two:2 };
Semi-formally that syntax looks like:
function-call:
name-token '(' parameter-list ')' // existing form
name-token object-literal // proposal
Existing grammar:
CallExpression Arguments
Arguments :
( )
( ArgumentList )
To add ObjectLiteral, at very least the grammar would need to have a
NoLineTerminator between CallExpression and Arguments, which breaks extant
code.
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [proposal] Function calls, syntax sugar
A slightly less ambitious suggestion: consider f() as syntax for the implicit arguments array (which, as of ES6, can be considered deprecated), then make the parens in this syntax optional In other words, you could write f 1 // single parameter f(1,2)// single parameter, implicit arguments pseudo-array f [1,2]// single parameter, explicit array Things get more interesting when you consider currying (functions returning functions): f(1)(2) // conventional, implicit arguments pseudo-arrays f 1 2// paren-free, single parameters, no arrays For your nested call example, you'd have the choice between foo(1, 2, bar(a, b))//uncurried, implicit pseudo-arrays foo[1, 2, bar[a, b]]// uncurried, explicit arrays foo 1 2 (bar a b)// curried, single parameters In the latter variant, () are used for grouping, consistent with their use in the rest of the language. Nice as this would be, I don't know whether this can be fitted into ES grammar and ASI... (probably not?). Claus PS. could es-discuss-owner please check their mailbox (and update the mailing list info page)? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maps and Sets, goodbye polyfill ?!
In general, generators are very hard to polyfill. (Not impossible, as
you can do a CPS transform of the source code, but very difficult.)
It depends on what you want. For concise specification of iteration,
you can do something without full CPS transform, by using monadic
coding style. My scratch area for monadic generators and promises:
monadic javascript/typescript: promises and generators
https://gist.github.com/clausreinke/5984869
(which you can run with TypeScript 0.9, playground or npm)
Given that JS control-structures aren't predefined but built-in, we can't
redefine them but have to define our own, but it still isn't too bad. For
instance, the simple generator example
https://gist.github.com/clausreinke/5984869#file-monadic-ts-L492-L506
outputs
// Generator.forIn, with yield, plain iteration (prefix #)
# yield1 1
(yield1 returns 0)
# yield2 1
(yield2 returns 1)
# yield1 2
(yield1 returns 2)
# yield2 4
(yield2 returns 3)
# yield1 3
(yield1 returns 4)
# yield2 9
(yield2 returns 5)
# 1,2,3
Note from the iteration loop that I've implemented a functional API
(next returns {done,value,next}) instead of an imperative one (next
returns {done,value} and modifies its host).
The standard recursive tree generator
https://gist.github.com/clausreinke/5984869#file-monadic-ts-L521-L529
even looks readable without special syntax
function iterTree(tree) {
return Array.isArray(tree)
? tree.map( iterTree ).reduce( (x,y)= x.then( _= y ),
G.of(undefined) )
: G.yield(tree);
}
var generator3 = iterTree([1,[],[[2,3],4],5]);
MonadId.forOf( generator3, y= (console.log(* +y), MonadId.of(y)) );
and outputs
// MonadId.forOf, iterTree recursive generator() (prefix *)
* 1
* 2
* 3
* 4
* 5
With a very little syntactic sugar for monads (monad comprehensions,
monadic do notation), it could even be made to look like conventional
code. This has come up several times here, and would have a very high
value for very small cost, if done right.
Claus
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Questions on clz and toInteger
On Jul 11, 2013, at 9:01 PM, Luke Hoban wrote:
Two questions on new Number APIs:
1) Is it intentional that clz is on Number.prototype instead of Number? Why?
Generally, operations that operate upon a value of a specific type are
expressed as instance methods. We see this all the time with regular objects
but we also we see this in String where we have many methods that operate upon
string values. For Number we have the toFixed, etc. methods that convert
number values to strings. To me, clz seem like it fall into this category of
method that operate upon instances of a specific type. For example, compare
and contrast:
'00101000'.indexOf('1') // 2
0x28f0f0f0.clz() //2
both use instance methods, applied to a primitive value, that report something
about the structure of the value
The (new) is* methods on the Number constructor are generally different in that
they are predicates that test values that may not actually be numbers so they
can't be Number.prototype methods.
I think there is a stronger case to me made for Math.clz(number).
Number.prototype and Math both seem like plausible homes for clz. In the end,
I placed it on Number prototype because it is an operation that is specific to
a particular numeric encoding rather than an implementation of a general
mathematical function.
2) Is it intentional that Number.toInteger(Infinity) returns true?
Huh? How's that?
Number.toInteger is specified as the single step:
1 Return ToInteger(number)
and step 4 of the abstract operation ToInteger(number):
4 If number is +0, -0, +∞, or -∞, return number.
Luke
___
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: Questions on clz and toInteger
From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] On Jul 11, 2013, at 9:01 PM, Luke Hoban wrote: Two questions on new Number APIs: 1) Is it intentional that clz is on Number.prototype instead of Number? Why? I think there is a stronger case to me made for Math.clz(number). Number.prototype and Math both seem like plausible homes for clz. In the end, I placed it on Number prototype because it is an operation that is specific to a particular numeric encoding rather than an implementation of a general mathematical function. Yeah, I think Math would have been less surprising. I don't feel strongly, but Number.prototype wasn't what I had expected. 2) Is it intentional that Number.toInteger(Infinity) returns true? Huh? How's that? Number.toInteger is specified as the single step: 1 Return ToInteger(number) and step 4 of the abstract operation ToInteger(number): 4 If number is +0, -0, +∞, or -∞, return number. Sorry, I meant 'isInteger'. Per your quoted section, toInteger(Infinity) is Infinity, so isInteger(Infinity) is true. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Questions on clz and toInteger
On Fri, Jul 12, 2013 at 8:58 AM, Luke Hoban lu...@microsoft.com wrote: From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] On Jul 11, 2013, at 9:01 PM, Luke Hoban wrote: Two questions on new Number APIs: 1) Is it intentional that clz is on Number.prototype instead of Number? Why? I think there is a stronger case to me made for Math.clz(number). Number.prototype and Math both seem like plausible homes for clz. In the end, I placed it on Number prototype because it is an operation that is specific to a particular numeric encoding rather than an implementation of a general mathematical function. Yeah, I think Math would have been less surprising. I don't feel strongly, but Number.prototype wasn't what I had expected. 2) Is it intentional that Number.toInteger(Infinity) returns true? Huh? How's that? Number.toInteger is specified as the single step: 1 Return ToInteger(number) and step 4 of the abstract operation ToInteger(number): 4 If number is +0, -0, +∞, or -∞, return number. Sorry, I meant 'isInteger'. Per your quoted section, toInteger(Infinity) is Infinity, so isInteger(Infinity) is true. And I find that equally bizarre and unpleasant. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Text by me above is hereby placed in the public domain Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [proposal] Function calls, syntax sugar
On Fri, Jul 12, 2013 at 11:07 AM, Claus Reinke claus.rei...@talk21.comwrote:
A slightly less ambitious suggestion:
consider f() as syntax for the implicit arguments array
(which, as of ES6, can be considered deprecated), then
make the parens in this syntax optional
snip
In other words, you could write
f 1 // single parameter
f(1,2)// single parameter, implicit arguments pseudo-array
This breaks CallExpression Arguments...
Given:
function f(a, b) {
return [a, b];
}
Currently:
f(1, 2); // [1, 2]
Whereas...
// single parameter, implicit arguments pseudo-array:
f(1, 2);
|a| would be magically be treated like a ...rest param that wasn't really
an array, but instead a implicit arguments pseudo-array?
// [[1, 2], undefined]
f [1,2]// single parameter, explicit array
snip
For your nested call example, you'd have the choice between
foo(1, 2, bar(a, b))//uncurried, implicit pseudo-arrays
foo[1, 2, bar[a, b]]// uncurried, explicit arrays
Optional parens for CallExpression Arguments or MemberExpression
Arguments results in convoluted argument lists. The solutions shown above
using [] also create ambiguity with:
- MemberExpression[ Expression ]
- CallExpression[ Expression ]
Given:
function foo(value) {
return value;
}
foo.prop = Some data;
Currently:
foo(prop); // prop
foo[prop]; // Some data
Whereas...
foo[1, 2, bar[a, b]]// uncurried, explicit arrays
foo[prop] // What does this return?
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [proposal] Function calls, syntax sugar
function f(a, b) {
return [a, b];
}
Currently:
f(1, 2); // [1, 2]
Whereas...
// single parameter, implicit arguments pseudo-array:
f(1, 2);
|a| would be magically be treated like a ...rest param that wasn't really
an array, but instead a implicit arguments pseudo-array?
// [[1, 2], undefined]
No, just another way to describe the current situation, where
function f() {return [...arguments]}// pseudo code
f(1,2) // [1,2]
or, if we make the arguments explicit
function f(...arguments) {return [...arguments]}// pseudo code
f(1,2) // [1,2]
and explicit formal parameters would be destructured from arguments,
so
function f(a,b) {return [a,b]}
f(1,2) // [1,2]
The solutions shown above using [] also create ambiguity with:
- MemberExpression[ Expression ]
- CallExpression[ Expression ]
Given:
function foo(value) {
return value;
}
foo.prop = Some data;
Currently:
foo(prop); // prop
foo[prop]; // Some data
ah, yes, I knew there had to be a serious flaw somewhere... sigh
Claus
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: On IE __proto__ test cases
On Jul 11, 2013, at 9:33 PM, Mark S. Miller wrote:
Yes, that was intentional. Even though the __proto__: looks related to the
__proto__ property initially on Object.prototype, that's only cosmetic. It
is now simply part of the object literal syntax, in just the same way that
| used to just be special syntax.
Agreed, this is intentional.
This does seem to leave a hole in the functionality compared to |, which
is, how do you create a normal property named __proto__. The answer is the
computed property syntax: {[__proto__]: ...}.
I don't remember what whether we decided that {__proto__: ...} means the
same thing as {[__proto__]: ...} or {__proto__: ...}. I think we decided
the second, which probably better follows the principle of least surprise.
OTOH, the first would have kept JavaScript closes to JSON.
There are various possible issues here. First, as the spec. is now written
{__proto__: ...} and {__proto__:...} mean exactly the same thing.
Also, I think we still have an issue as to whether or not we want to allow
computed property keys (in propName positions) to produce string-valued keys.
When we first were considered computed propNames there were some objections
(Ollie Hunt??) to allowing string values. My recollection was that it
potentially forced turning the static checks for things like duplicate property
names in object literals into dynamic checks. My fuzzy recollection is that at
that time we decided to disallowed string valued computed propNames (this is
before we temporarily eliminated computed propNames in favor of at-names). I
think there was some discussion of this at the last meeting but I don't feel
that we have adequate re-explored the earlier decisions (?) to not allow
string valued propName. So, in the current draft I only allow Symbol valued
computed propNames but have it marked as a open issue.
If I turn on string valued computed propNames in the spec, then as currently
written {__proto__: ...} and {[__proto__]: ...} will have the same meaning.
We can, of course, change that but it will significant complicate the delta
spec. needed in Annex B for __proto__ in object literals.
finally, note that the current spec. only assigns special meaning to __proto__
for the production:
PropertyDefinition: PropertyName : AssignmentExpression
that means that things like:
let __proto__= { };
( {__proto__})
and
({__proto__ (arg) {}})
produce object with regular own properties named __proto__.
Allen
On Thu, Jul 11, 2013 at 9:06 PM, Luke Hoban lu...@microsoft.com wrote:
From: es-discuss-boun...@mozilla.org
[mailto:es-discuss-boun...@mozilla.org] On Behalf Of Erik Arvidsson
Yeah, these test all look incorrect to me. IE11 implements an older draft
where __proto__ was a magic property.
That’s right. Our implementation predates the May spec updates that changed
the spec for __proto__. We will update the test contributions to tests262 to
align with the updated spec.
One question from looking at implications of this change. Is it intentional
that there is no longer a way to remove (or customize) the special handling
of __proto__ in object literals?
delete Object.prototype.__proto__
var p = { y: 34 }
var o = { x: 42, __proto__: y }
o.y === 34 // was false, now true
Luke
___
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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Why is .bind so slow?
The TypeScript project tries to emulate arrow functions through the _this = this pattern and keeps running into corner cases where a semi-naïve renaming is not sufficient. I have been trying to suggest using .bind to emulate arrow functions instead, but the counter-arguments are (a) .bind might not be available (supporting pre-ES5 targets) and (b) .bind is slow. The polyfill isn't the problem, but I'm a bit shocked every time someone reminds me of the performance hit for using .bind. Given that a bound function has strictly more info than an unbound one, I wouldn't expect that (I expected a bound function to be roughly the same as an unbound function that does not use this). Unless there is no special casing for the just-add-this case, and .bind is always treated as a non-standard (meta-level) call. While playing with test-code, I also found that v8 does a lot better than other engines when using an .apply-based .bind emulation. Can anyone explain what is going on with .bind, .apply and the performance hits? The TypeScript issue is https://typescript.codeplex.com/workitem/1322 . My test code (*) is attached there as bind-for-arrows.html. Claus http://clausreinke.github.com/ (*) I also tried to make a jsperf test case, but the way jsperf runs the loop seems to prevent the optimization that makes v8 look good for the .apply-based bind. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Questions on clz and toInteger
On Jul 12, 2013, at 9:01 AM, Mark Miller wrote: On Fri, Jul 12, 2013 at 8:58 AM, Luke Hoban lu...@microsoft.com wrote: From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] 2) Is it intentional that Number.toInteger(Infinity) returns true? Huh? How's that? Number.toInteger is specified as the single step: 1 Return ToInteger(number) and step 4 of the abstract operation ToInteger(number): 4 If number is +0, -0, +∞, or -∞, return number. Sorry, I meant 'isInteger'. Per your quoted section, toInteger(Infinity) is Infinity, so isInteger(Infinity) is true. And I find that equally bizarre and unpleasant. ToInteger is an internal operation. Algorithms that call it can explicitly check for infinities if it is important to them. However, a quick scan of its current uses shows that passing through infinities is exactly want is needed in most cases. Number.toInteger is a language level function and it is certainly reasonable to explicitly discuss what it should return for infinities (and for that matter NaN and -0). So what do you think it should do for those cases? Also, the current Math.isInteger spec. is just plan bogus: 3. If integer is not equal to number, return false. What (in the spec.) does not equal mean? I must have been asleep at the keyboard or maybe it's strawman language that slipped through into the spec. without adequate review... Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why is .bind so slow?
you might consider ticketing performance bugs against the various implementations. Allen On Jul 10, 2013, at 9:16 AM, Claus Reinke wrote: The TypeScript project tries to emulate arrow functions through the _this = this pattern and keeps running into corner cases where a semi-naïve renaming is not sufficient. I have been trying to suggest using .bind to emulate arrow functions instead, but the counter-arguments are (a) .bind might not be available (supporting pre-ES5 targets) and (b) .bind is slow. The polyfill isn't the problem, but I'm a bit shocked every time someone reminds me of the performance hit for using .bind. Given that a bound function has strictly more info than an unbound one, I wouldn't expect that (I expected a bound function to be roughly the same as an unbound function that does not use this). Unless there is no special casing for the just-add-this case, and .bind is always treated as a non-standard (meta-level) call. While playing with test-code, I also found that v8 does a lot better than other engines when using an .apply-based .bind emulation. Can anyone explain what is going on with .bind, .apply and the performance hits? The TypeScript issue is https://typescript.codeplex.com/workitem/1322 . My test code (*) is attached there as bind-for-arrows.html. Claus http://clausreinke.github.com/ (*) I also tried to make a jsperf test case, but the way jsperf runs the loop seems to prevent the optimization that makes v8 look good for the .apply-based bind. ___ 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: Object#extra hazard
With the availability of constants and Symbols you could easily create what
SHOULD be a memory efficient event library.
On Thu, Jul 11, 2013 at 3:04 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
trivial like ... 2 weak maps + a set for a single event ?
```javascript
obj.on(evt, handler);
```
.. internals ...
```javascript
// wm as private internal generic WeakMap
if (!wm.has(obj)) {
// creates related WeakMap
wm.set(obj, new WeakMap);
}
if (!wm.get(obj).has(evt)) {
wm.get(obj).set(evt, new Set);
}
wm.get(obj).get(evt).add(handler);
```
I have the feeling it's very true in JS world nobody ever thinks about RAM
and GC ^_^
That said, it becomes over complicated for non concrete reason/use case if
we have strings since AFAIK WeakMap does not accept strings as key.
For all this time the event type as string has blocked like ... nobody
ever ? I wonder again what's the benefit then to instantly over complicate
an API at this stage instead of looking around what worked already for
everyone.
Maybe it's me not seeing the power of objects as events.
br
On Thu, Jul 11, 2013 at 2:32 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Thu, Jul 11, 2013 at 4:45 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I would simplify saying that symbols can be used as well as strings ? I
don't see any usefulness into using an object as event type and I think if
we start olready over-engineered/complicated this will never see the light
in any spec which is a lost/lost if you ask me
It's trivial if an Emitter uses something like [[MapData]] or
[[WeakMapData]] as it's internal data property for event storage.
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Questions on clz and toInteger
On Jul 12, 2013, at 8:58 AM, Luke Hoban lu...@microsoft.com wrote: From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] On Jul 11, 2013, at 9:01 PM, Luke Hoban wrote: Two questions on new Number APIs: 1) Is it intentional that clz is on Number.prototype instead of Number? Why? I think there is a stronger case to me made for Math.clz(number). Number.prototype and Math both seem like plausible homes for clz. In the end, I placed it on Number prototype because it is an operation that is specific to a particular numeric encoding rather than an implementation of a general mathematical function. Yeah, I think Math would have been less surprising. I don't feel strongly, but Number.prototype wasn't what I had expected. I agree with luke, Math.clz seems like a better place than the prototype, otoh there's a nice conciseness to foo.clz() … 2) Is it intentional that Number.toInteger(Infinity) returns true? Huh? How's that? Number.toInteger is specified as the single step: 1 Return ToInteger(number) and step 4 of the abstract operation ToInteger(number): 4 If number is +0, -0, +∞, or -∞, return number. Sorry, I meant 'isInteger'. Per your quoted section, toInteger(Infinity) is Infinity, so isInteger(Infinity) is true. I agree with MarkM that it seems bizarre that non-finite numbers may return true, but i think this is rooted in .isInteger() sounding like it means a 32bit integer (such that bitops won't modify the value) when it is actually a no fractional component test. --Oliver ___ 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: Questions on clz and toInteger
On Fri, Jul 12, 2013 at 10:19 AM, Mark S. Miller erig...@google.com wrote: No. Even if toInteger meant no fractional component, I would still expect it only to return true if there is some specific mathematical integer that the JS number can be said to exactly represent. For the same reason, I think isInteger(-0) should be true and isInteger(NaN) should be false. Agreed. isInteger() has one job, and it's kinda worthless if it can't even do that. How it should be: Number.isInteger(-0) == true Number.isInteger(NaN) == false Number.isInteger(Infinity) == false And, because of what we discussed in the recent thread... Number.isInteger(Math.pow(2,53)-1) == true Number.isInteger(Math.pow(2,53)) == false ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why is .bind so slow?
I think we all know that's extremely slow and since ever. I always wondered the reason too ... in jsperf there are tons of tests about this, here yet another one just quickly created to compare the gap: http://jsperf.com/bind-is-slow in Chrome, bind(context) without even arguments is 87% slower than a closure with call On Fri, Jul 12, 2013 at 10:09 AM, Mark S. Miller erig...@google.com wrote: If you can manage it, most effective would be to get .bind (or any other operation you want to be faster) into some widely quoted benchmark suite. On Fri, Jul 12, 2013 at 9:46 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: you might consider ticketing performance bugs against the various implementations. Allen On Jul 10, 2013, at 9:16 AM, Claus Reinke wrote: The TypeScript project tries to emulate arrow functions through the _this = this pattern and keeps running into corner cases where a semi-naïve renaming is not sufficient. I have been trying to suggest using .bind to emulate arrow functions instead, but the counter-arguments are (a) .bind might not be available (supporting pre-ES5 targets) and (b) .bind is slow. The polyfill isn't the problem, but I'm a bit shocked every time someone reminds me of the performance hit for using .bind. Given that a bound function has strictly more info than an unbound one, I wouldn't expect that (I expected a bound function to be roughly the same as an unbound function that does not use this). Unless there is no special casing for the just-add-this case, and .bind is always treated as a non-standard (meta-level) call. While playing with test-code, I also found that v8 does a lot better than other engines when using an .apply-based .bind emulation. Can anyone explain what is going on with .bind, .apply and the performance hits? The TypeScript issue is https://typescript.codeplex.com/workitem/1322 . My test code (*) is attached there as bind-for-arrows.html. Claus http://clausreinke.github.com/ (*) I also tried to make a jsperf test case, but the way jsperf runs the loop seems to prevent the optimization that makes v8 look good for the .apply-based bind. ___ 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 -- Cheers, --MarkM ___ 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: [proposal] Function calls, syntax sugar
On Fri, Jul 12, 2013 at 6:45 AM, Rick Waldron waldron.r...@gmail.com wrote:
On Fri, Jul 12, 2013 at 12:22 AM, Andrew Fedoniouk
n...@terrainformatica.com wrote:
Quite often I see constructions like this:
foo({one:1,two:2});
so call of function with single parameter - object literal.
Idiom named Poor man named arguments passing
Idea is to extend existing JS/ES syntax calls to support
simple form of the call above:
foo {one:1,two:2 };
Semi-formally that syntax looks like:
function-call:
name-token '(' parameter-list ')' // existing form
name-token object-literal // proposal
Given:
function foo(){ return 1; }
This is a valid function call:
foo
()
// 1;
But this is valid, too (though, not a function call):
foo -- identifier
{} -- empty block
// function foo() { return 1; }
This construction
foo {};
is an equivalent of:
foo({});
but not
foo();
To call function with empty param list you still need empty '('')' brackets.
Also, I could be wrong, but wouldn't there need to be a way to disambiguate
UnaryExpression?
typeof foo { one: 1, two: 2 }
Maybe this is not an issue, or easily dealt with?
This is not an issue. Parsed exactly the same as:
typeof foo({ one: 1, two: 2 })
--
Andrew Fedoniouk.
http://terrainformatica.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Questions on clz and toInteger
On Jul 12, 2013, at 10:19 AM, Mark S. Miller erig...@google.com wrote: No. Even if toInteger meant no fractional component, I would still expect it only to return true if there is some specific mathematical integer that the JS number can be said to exactly represent. For the same reason, I think isInteger(-0) should be true and isInteger(NaN) should be false. Oh i agree with that, i was making an observation that the behaviour (i think) will confuse people just on the basis of people equating Int32 with Integer --Oliver On Fri, Jul 12, 2013 at 10:16 AM, Oliver Hunt oli...@apple.com wrote: On Jul 12, 2013, at 8:58 AM, Luke Hoban lu...@microsoft.com wrote: From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] On Jul 11, 2013, at 9:01 PM, Luke Hoban wrote: Two questions on new Number APIs: 1) Is it intentional that clz is on Number.prototype instead of Number? Why? I think there is a stronger case to me made for Math.clz(number). Number.prototype and Math both seem like plausible homes for clz. In the end, I placed it on Number prototype because it is an operation that is specific to a particular numeric encoding rather than an implementation of a general mathematical function. Yeah, I think Math would have been less surprising. I don't feel strongly, but Number.prototype wasn't what I had expected. I agree with luke, Math.clz seems like a better place than the prototype, otoh there's a nice conciseness to foo.clz() … 2) Is it intentional that Number.toInteger(Infinity) returns true? Huh? How's that? Number.toInteger is specified as the single step: 1 Return ToInteger(number) and step 4 of the abstract operation ToInteger(number): 4 If number is +0, -0, +∞, or -∞, return number. Sorry, I meant 'isInteger'. Per your quoted section, toInteger(Infinity) is Infinity, so isInteger(Infinity) is true. I agree with MarkM that it seems bizarre that non-finite numbers may return true, but i think this is rooted in .isInteger() sounding like it means a 32bit integer (such that bitops won't modify the value) when it is actually a no fractional component test. --Oliver ___ 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 -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
JS Ctypes
I wonder if there is any interest/plan/scheduled TC39 slot about JS Ctypes, mentioned by [Brendan Eich in his famous TXJS talk]( https://brendaneich.com/2011/08/my-txjs-talk-twitter-remix/) but never again discussed in this ml. Seeing `asm.js` passing through all usual procedures before `JS Ctypes` I wonder if the latter one is still a thing or it will be abandoned (or it has already been abandoned) Not only other JS engines do not expose these nice and potentially ultra fast typed structs/primitives, when I've benchmarked them a while ago somebody mentioned these are not even JITed in any *Monkey engine. Thanks for any news about this once awesome idea. Best Regards ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why is .bind so slow?
On Jul 12, 2013, at 10:09 AM, Mark S. Miller erig...@google.com wrote: If you can manage it, most effective would be to get .bind (or any other operation you want to be faster) into some widely quoted benchmark suite. In WebKit at least, we have a thing called JSRegress which is meant to be a dumping ground for benchmarks for interesting corners of the language. Microbenchmarks are welcome; the goal is to just expand coverage of things that we measure timings of. It's not widely quoted, and it doesn't get the same priority as macrobenchmark suites, but we do care about it and we do optimize for it. For example, all of our optimization a for typeof, switch, and 'in' arose from JSRegress tests, since none of those things were hot enough in any of the major benchmarks. We don't have coverage for bind, and it would be great to fix that. If you have a standalone program that uses bind, you can either post a patch on bugs.webkit.org that adds it to JSRegress (I.e. LayoutTests/fast/js/regress/script-tests), or if you're lazy, you can just email the program to me and I can do the footwork. The less micro-benchmarky the better, but we'll take what we can get. If you have multiple such benchmarks for bind then that's even better still. TL;DR getting a benchmark to have visibility among implementors is as easy as telling them about it. -Filip On Fri, Jul 12, 2013 at 9:46 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: you might consider ticketing performance bugs against the various implementations. Allen On Jul 10, 2013, at 9:16 AM, Claus Reinke wrote: The TypeScript project tries to emulate arrow functions through the _this = this pattern and keeps running into corner cases where a semi-naïve renaming is not sufficient. I have been trying to suggest using .bind to emulate arrow functions instead, but the counter-arguments are (a) .bind might not be available (supporting pre-ES5 targets) and (b) .bind is slow. The polyfill isn't the problem, but I'm a bit shocked every time someone reminds me of the performance hit for using .bind. Given that a bound function has strictly more info than an unbound one, I wouldn't expect that (I expected a bound function to be roughly the same as an unbound function that does not use this). Unless there is no special casing for the just-add-this case, and .bind is always treated as a non-standard (meta-level) call. While playing with test-code, I also found that v8 does a lot better than other engines when using an .apply-based .bind emulation. Can anyone explain what is going on with .bind, .apply and the performance hits? The TypeScript issue is https://typescript.codeplex.com/workitem/1322 . My test code (*) is attached there as bind-for-arrows.html. Claus http://clausreinke.github.com/ (*) I also tried to make a jsperf test case, but the way jsperf runs the loop seems to prevent the optimization that makes v8 look good for the .apply-based bind. ___ 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 -- Cheers, --MarkM ___ 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: Questions on clz and toInteger
On Jul 12, 2013, at 10:27 AM, Tab Atkins Jr. wrote: On Fri, Jul 12, 2013 at 10:19 AM, Mark S. Miller erig...@google.com wrote: No. Even if toInteger meant no fractional component, I would still expect it only to return true if there is some specific mathematical integer that the JS number can be said to exactly represent. For the same reason, I think isInteger(-0) should be true and isInteger(NaN) should be false. Agreed. isInteger() has one job, and it's kinda worthless if it can't even do that. How it should be: Number.isInteger(-0) == true Number.isInteger(NaN) == false Number.isInteger(Infinity) == false And, because of what we discussed in the recent thread... Number.isInteger(Math.pow(2,53)-1) == true Number.isInteger(Math.pow(2,53)) == false In other words you want to define Number.isInteger to return true only if it's argument is an integer number in the range -(2^53-1)..2^53-1 That's a useful test and a plausible definition of Number.isInteger but it will also probably be surprising to programmers who are familiar with the esoterics of IEEE floats. If we went that direction what should Number.toInteger do for values outside that range? Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [syntax] arrow function notation is too greedy
Andrew Fedoniouk wrote: So that can be compiled to stack machine strictly in order it is defined. Or do you mean something else here? You're right, that case can be handled, but the for loops and the left-hand side revisions remain. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why is .bind so slow?
Just to clarify, JSRegress is not a benchmark in the sunspider/kraken/etc sense, as the tests tend far more towards microbenchmarks than full real programme tests. As the name suggests its main purpose is to help us make sure we're not regressing core language primitives. --Oliver On Jul 12, 2013, at 10:49 AM, Filip Pizlo fpi...@apple.com wrote: On Jul 12, 2013, at 10:09 AM, Mark S. Miller erig...@google.com wrote: If you can manage it, most effective would be to get .bind (or any other operation you want to be faster) into some widely quoted benchmark suite. In WebKit at least, we have a thing called JSRegress which is meant to be a dumping ground for benchmarks for interesting corners of the language. Microbenchmarks are welcome; the goal is to just expand coverage of things that we measure timings of. It's not widely quoted, and it doesn't get the same priority as macrobenchmark suites, but we do care about it and we do optimize for it. For example, all of our optimization a for typeof, switch, and 'in' arose from JSRegress tests, since none of those things were hot enough in any of the major benchmarks. We don't have coverage for bind, and it would be great to fix that. If you have a standalone program that uses bind, you can either post a patch on bugs.webkit.org that adds it to JSRegress (I.e. LayoutTests/fast/js/regress/script-tests), or if you're lazy, you can just email the program to me and I can do the footwork. The less micro-benchmarky the better, but we'll take what we can get. If you have multiple such benchmarks for bind then that's even better still. TL;DR getting a benchmark to have visibility among implementors is as easy as telling them about it. -Filip On Fri, Jul 12, 2013 at 9:46 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: you might consider ticketing performance bugs against the various implementations. Allen On Jul 10, 2013, at 9:16 AM, Claus Reinke wrote: The TypeScript project tries to emulate arrow functions through the _this = this pattern and keeps running into corner cases where a semi-naïve renaming is not sufficient. I have been trying to suggest using .bind to emulate arrow functions instead, but the counter-arguments are (a) .bind might not be available (supporting pre-ES5 targets) and (b) .bind is slow. The polyfill isn't the problem, but I'm a bit shocked every time someone reminds me of the performance hit for using .bind. Given that a bound function has strictly more info than an unbound one, I wouldn't expect that (I expected a bound function to be roughly the same as an unbound function that does not use this). Unless there is no special casing for the just-add-this case, and .bind is always treated as a non-standard (meta-level) call. While playing with test-code, I also found that v8 does a lot better than other engines when using an .apply-based .bind emulation. Can anyone explain what is going on with .bind, .apply and the performance hits? The TypeScript issue is https://typescript.codeplex.com/workitem/1322 . My test code (*) is attached there as bind-for-arrows.html. Claus http://clausreinke.github.com/ (*) I also tried to make a jsperf test case, but the way jsperf runs the loop seems to prevent the optimization that makes v8 look good for the .apply-based bind. ___ 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 -- Cheers, --MarkM ___ 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: Why is .bind so slow?
Allen Wirfs-Brock wrote: you might consider ticketing performance bugs against the various implementations. Right, and at most summarize with links to those issues for es-discuss. This is not a language issue, rather a quality of implementation one. /be Allen On Jul 10, 2013, at 9:16 AM, Claus Reinke wrote: The TypeScript project tries to emulate arrow functions through the _this = this pattern and keeps running into corner cases where a semi-naïve renaming is not sufficient. I have been trying to suggest using .bind to emulate arrow functions instead, but the counter-arguments are (a) .bind might not be available (supporting pre-ES5 targets) and (b) .bind is slow. The polyfill isn't the problem, but I'm a bit shocked every time someone reminds me of the performance hit for using .bind. Given that a bound function has strictly more info than an unbound one, I wouldn't expect that (I expected a bound function to be roughly the same as an unbound function that does not use this). Unless there is no special casing for the just-add-this case, and .bind is always treated as a non-standard (meta-level) call. While playing with test-code, I also found that v8 does a lot better than other engines when using an .apply-based .bind emulation. Can anyone explain what is going on with .bind, .apply and the performance hits? The TypeScript issue is https://typescript.codeplex.com/workitem/1322 . My test code (*) is attached there as bind-for-arrows.html. Claus http://clausreinke.github.com/ (*) I also tried to make a jsperf test case, but the way jsperf runs the loop seems to prevent the optimization that makes v8 look good for the .apply-based bind. ___ 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: Questions on clz and toInteger
On Fri, Jul 12, 2013 at 10:48 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jul 12, 2013, at 10:27 AM, Tab Atkins Jr. wrote: On Fri, Jul 12, 2013 at 10:19 AM, Mark S. Miller erig...@google.com wrote: No. Even if toInteger meant no fractional component, I would still expect it only to return true if there is some specific mathematical integer that the JS number can be said to exactly represent. For the same reason, I think isInteger(-0) should be true and isInteger(NaN) should be false. Agreed. isInteger() has one job, and it's kinda worthless if it can't even do that. How it should be: Number.isInteger(-0) == true Number.isInteger(NaN) == false Number.isInteger(Infinity) == false And, because of what we discussed in the recent thread... Number.isInteger(Math.pow(2,53)-1) == true Number.isInteger(Math.pow(2,53)) == false In other words you want to define Number.isInteger to return true only if it's argument is an integer number in the range -(2^53-1)..2^53-1 That's a useful test and a plausible definition of Number.isInteger but it will also probably be surprising to programmers who are familiar with the esoterics of IEEE floats. On the other hand, people (like me) who just want to be able to tell when something is a freaking integer will be better served by these semantics. ^_^ If we went that direction what should Number.toInteger do for values outside that range? The internal operation just returns 0 for things that aren't integers. I'd be okay with that, I suppose. (I use a similar function in some of my own code, and return false from the operation when the number cant' be converted, but that's because I use it as a combination tester and converter. We have an explicit tester, so I'm fine with the converter hiding details of its conversion.) ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: JS Ctypes
JSCTypes is unsafe, it won't be standardized and we restrict access to Firefox add-ons and chrome (privileged UX implementation) code. Binary data and value objects cover the fast typed structs/primitives. Unsafe FFI is a different issue and should not be mixed up with structs and scalar/SIMD-vector types. It's also not awesome because unsafe. /be Andrea Giammarchi wrote: I wonder if there is any interest/plan/scheduled TC39 slot about JS Ctypes, mentioned by [Brendan Eich in his famous TXJS talk](https://brendaneich.com/2011/08/my-txjs-talk-twitter-remix/) but never again discussed in this ml. Seeing `asm.js` passing through all usual procedures before `JS Ctypes` I wonder if the latter one is still a thing or it will be abandoned (or it has already been abandoned) Not only other JS engines do not expose these nice and potentially ultra fast typed structs/primitives, when I've benchmarked them a while ago somebody mentioned these are not even JITed in any *Monkey engine. Thanks for any news about this once awesome idea. Best Regards ___ 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: [syntax] arrow function notation is too greedy
Brendan Eich wrote: Andrew Fedoniouk wrote: So that can be compiled to stack machine strictly in order it is defined. Or do you mean something else here? You're right, that case can be handled, but the for loops and the left-hand side revisions remain. Sorry, callee revisions. Depending on how you generate code, you can do a lot in one pass, but the for loops require reorder buffers, and using too slow a target machine just to get one pass compile can lose if the code is hot. But the point remains: the language never had single-pass no-reorder codegen, in 1995 from its birth onward. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: JS Ctypes
python has ctypes and is widely used, having something similar in JS would have been awesome too, didn't know it was unsafe. Is that because of the proposal or because JS is not suitable for user managed structs? Thanks On Fri, Jul 12, 2013 at 11:01 AM, Brendan Eich bren...@mozilla.com wrote: JSCTypes is unsafe, it won't be standardized and we restrict access to Firefox add-ons and chrome (privileged UX implementation) code. Binary data and value objects cover the fast typed structs/primitives. Unsafe FFI is a different issue and should not be mixed up with structs and scalar/SIMD-vector types. It's also not awesome because unsafe. /be Andrea Giammarchi wrote: I wonder if there is any interest/plan/scheduled TC39 slot about JS Ctypes, mentioned by [Brendan Eich in his famous TXJS talk]( https://brendaneich.com/**2011/08/my-txjs-talk-twitter-**remix/https://brendaneich.com/2011/08/my-txjs-talk-twitter-remix/) but never again discussed in this ml. Seeing `asm.js` passing through all usual procedures before `JS Ctypes` I wonder if the latter one is still a thing or it will be abandoned (or it has already been abandoned) Not only other JS engines do not expose these nice and potentially ultra fast typed structs/primitives, when I've benchmarked them a while ago somebody mentioned these are not even JITed in any *Monkey engine. Thanks for any news about this once awesome idea. Best Regards __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [proposal] Function calls, syntax sugar
On Fri, Jul 12, 2013 at 7:02 AM, Rick Waldron waldron.r...@gmail.com wrote:
On Fri, Jul 12, 2013 at 12:22 AM, Andrew Fedoniouk
n...@terrainformatica.com wrote:
Quite often I see constructions like this:
foo({one:1,two:2});
so call of function with single parameter - object literal.
Idiom named Poor man named arguments passing
Idea is to extend existing JS/ES syntax calls to support
simple form of the call above:
foo {one:1,two:2 };
Semi-formally that syntax looks like:
function-call:
name-token '(' parameter-list ')' // existing form
name-token object-literal // proposal
Existing grammar:
CallExpression Arguments
Arguments :
( )
( ArgumentList )
To add ObjectLiteral, at very least the grammar would need to have a
NoLineTerminator between CallExpression and Arguments, which breaks extant
code.
Yes, NoLineTerminator is required for non-strict mode (that ugly
semicolon elision
strikes again)
Even in non-strict mode this code:
function foo(obj) { return 1; }
var c = foo { one:1 };
produces parsing error before the '{' - semicolon required.
The same kind of error is in this case too:
function foo(p1,p2) { return 1; }
var c = foo 1,2;
So that syntax change will be backward compatible - it will
not change semantic of existing valid code.
--
Andrew Fedoniouk.
http://terrainformatica.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: JS Ctypes
On Fri, Jul 12, 2013 at 11:22 AM, Oliver Hunt oli...@apple.com wrote: Python isn't use to run arbitrary untrusted code, from untrusted websites. neither is node ... but actually, not even JS ... it could, of course, so could Python evaluate random generated code if needed. In few words I've always been skeptical about this point 'cause every script can mess up with both natives, memory, leaks, etc, etc The reality is that we thinking about features you want in ES, it's not enough for another language to have the feature, you have to ask yourself whether the other language is primarily used for untrusted code. I think nobody really use JS for untrusted code but even if that's the case, there should rather be a sandbox like approach to make that untrusted code harmless (iframe already do a good job for this). A directive such `use asm` could be used too as `use ctypes` except the latter one would be much more powerful and human readable/expressive than what `asm.js` can be. However, I didn't open this thread to complain, propose, or anything, I was wondering the reason Ctypes in JS has been abandoned so I am good, thanks. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [proposal] Function calls, syntax sugar
On Thu, Jul 11, 2013 at 9:22 PM, Andrew Fedoniouk
n...@terrainformatica.com wrote:
Quite often I see constructions like this:
foo({one:1,two:2});
so call of function with single parameter - object literal.
Idiom named Poor man named arguments passing
Idea is to extend existing JS/ES syntax calls to support
simple form of the call above:
foo {one:1,two:2 };
Semi-formally that syntax looks like:
function-call:
name-token '(' parameter-list ')' // existing form
name-token object-literal // proposal
This syntax extension will not break correct pre-ES6 code
as far as I can tell. But I am not sure about new ES6 arrivals.
In fact we can add even more generic form of function call:
foo 1,2,three;
that is an equivalent of foo(1,2,three);
In this case grammar may look like:
function-call:
name-token '(' parameter-list ')' // existing form
name-token parameter-list // proposal
Where parameter-list is comma ',' separated list of expressions.
Just to reduce that bracketing noise in syntax.
I'm not a fan of this, because it only gets us part of the way toward
the benefits of real named parameter support, and makes it even less
likely that we'll actually get to the end. Python has it good - every
argument can be given either by position or by name, and you can
collect both extra positional arguments and extra named arguments.
I'd prefer figuring out a syntax for argument lists that gives us the
same argument-list power as Python.
~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: JS Ctypes
Python isn't use to run arbitrary untrusted code, from untrusted websites. The reality is that we thinking about features you want in ES, it's not enough for another language to have the feature, you have to ask yourself whether the other language is primarily used for untrusted code. --Oliver On Jul 12, 2013, at 11:17 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: python has ctypes and is widely used, having something similar in JS would have been awesome too, didn't know it was unsafe. Is that because of the proposal or because JS is not suitable for user managed structs? Thanks On Fri, Jul 12, 2013 at 11:01 AM, Brendan Eich bren...@mozilla.com wrote: JSCTypes is unsafe, it won't be standardized and we restrict access to Firefox add-ons and chrome (privileged UX implementation) code. Binary data and value objects cover the fast typed structs/primitives. Unsafe FFI is a different issue and should not be mixed up with structs and scalar/SIMD-vector types. It's also not awesome because unsafe. /be Andrea Giammarchi wrote: I wonder if there is any interest/plan/scheduled TC39 slot about JS Ctypes, mentioned by [Brendan Eich in his famous TXJS talk](https://brendaneich.com/2011/08/my-txjs-talk-twitter-remix/) but never again discussed in this ml. Seeing `asm.js` passing through all usual procedures before `JS Ctypes` I wonder if the latter one is still a thing or it will be abandoned (or it has already been abandoned) Not only other JS engines do not expose these nice and potentially ultra fast typed structs/primitives, when I've benchmarked them a while ago somebody mentioned these are not even JITed in any *Monkey engine. Thanks for any news about this once awesome idea. Best Regards ___ 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: [proposal] Function calls, syntax sugar
On Fri, Jul 12, 2013 at 11:20 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Thu, Jul 11, 2013 at 9:22 PM, Andrew Fedoniouk
n...@terrainformatica.com wrote:
Quite often I see constructions like this:
foo({one:1,two:2});
so call of function with single parameter - object literal.
Idiom named Poor man named arguments passing
Idea is to extend existing JS/ES syntax calls to support
simple form of the call above:
foo {one:1,two:2 };
Semi-formally that syntax looks like:
function-call:
name-token '(' parameter-list ')' // existing form
name-token object-literal // proposal
This syntax extension will not break correct pre-ES6 code
as far as I can tell. But I am not sure about new ES6 arrivals.
Just to reduce that bracketing noise in syntax.
I'm not a fan of this, because it only gets us part of the way toward
the benefits of real named parameter support, and makes it even less
likely that we'll actually get to the end. Python has it good - every
argument can be given either by position or by name, and you can
collect both extra positional arguments and extra named arguments.
I'd prefer figuring out a syntax for argument lists that gives us the
same argument-list power as Python.
Adding Python'ic way of handling parameters requires
substantial change of existing runtime architecture ('arguments' and around).
In contrary proposed
foo {one:1,two:2 };
requires just syntax change .
--
Andrew Fedoniouk.
http://terrainformatica.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Proposal: new Symbol(obj)
In brief: allow Symbol's to be constructed with a single parameter, with
the following behavior:
var obj = {};
undefined
new Symbol({}) === new Symbol({})
false
new Symbol(obj) === new Symbol(obj)
true
Motivation: the ability to construct equal Symbols gives us the necessary
building blocks to build custom maps with semantics very similar to Simple
Maps[1]:
function ObjectMap() {
this.map = {};
}
SimpleMap.prototype.set = function(objKey, val) {
this.map[new Symbol(objKey)] = val;
};
SimpleMap.prototype.get = function(objKey) {
return this.map[new Symbol(objKey)];
};
At a surface level, this seems more novelty than anything else, but I think
it's a useful primitive for building more complex and robust features on
top of Symbols. Thoughts?
[1] http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: new Symbol(obj)
On Jul 12, 2013, at 12:14 PM, Jeremy Martin wrote:
In brief: allow Symbol's to be constructed with a single parameter, with the
following behavior:
var obj = {};
undefined
new Symbol({}) === new Symbol({})
false
new Symbol(obj) === new Symbol(obj)
true
You can use a WeakMap to build your own object-selected Symbol factory:
let known = new WeakMap;
function ObjSymFactory(obj) {
//handle obj === undefined however you want
let sym = known.get(obj);
If (!sym) {
sym = new Symbol;
known.set(obj,sym);
}
return sym;
}
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: new Symbol(obj)
Good point, that's definitely a usable solution (also a better
representation of what I was attempting to describe).
I'd still be interested in a less-verbose/more-efficient approach using the
Symbol constructor, but it may not be a common enough scenario to justify
it when a workaround does exist.
On Fri, Jul 12, 2013 at 3:32 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Jul 12, 2013, at 12:14 PM, Jeremy Martin wrote:
In brief: allow Symbol's to be constructed with a single parameter, with
the following behavior:
var obj = {};
undefined
new Symbol({}) === new Symbol({})
false
new Symbol(obj) === new Symbol(obj)
true
You can use a WeakMap to build your own object-selected Symbol factory:
let known = new WeakMap;
function ObjSymFactory(obj) {
//handle obj === undefined however you want
let sym = known.get(obj);
If (!sym) {
sym = new Symbol;
known.set(obj,sym);
}
return sym;
}
Allen
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Why is .bind so slow?
I've had some back and forth with v8 devs about this since it affects my
compiler. I believe they already have open issues about it but I don't know
the bug #s.
In general, the problem seems to be that Function.bind creates functions
that have different type information from normal functions you wrote in
pure JS; they're 'special' native functions in the same fashion as say, a
DOM API:
document.createElement
function createElement() { [native code] }
function f () {}
f
function f() {}
f.bind(null)
function () { [native code] }
This is important because v8 tries to gather information about callees at
various call sites. Having a mix of these special and non-special functions
means that the JIT is not able to make safe optimizations based on all the
callers being the same type.
IIRC there are also some other problems specific to v8, like it only being
able to optimize Function.apply and Function.call if the .apply/.call
methods are the implementations used for pure-JS functions (so bind breaks
those too).
I can't comment on why it's slow in SpiderMonkey (I've never asked... I
should file a bug) but it is indeed the case that f.bind(null) produces a
'native code' function in SpiderMonkey, so I expect some of the same
optimization consequences apply.
I also expect that it is much harder for v8 and spidermonkey to inline a
function that contains native code, if not entirely impossible.
All of these problems, as I understand them, are completely fixable. It
might be as simple as making bind return a pure-JS function instead of a
native function. This is supported by the fact that a pure-JS polyfill for
.bind is usually faster in my tests. In general VM authors are much more
helpful when shown real world applications affected by these issues, based
on my experience. They tend to ignore jsperf microbenchmarks, etc.
I don't know that this could be addressed at all from a specification
perspective. The only thing I can think of would be specifying that the
result of Function.bind should somehow be indistinguishable from a
hand-written JS function (no 'native code' in tostring, etc) but I don't
think that sort of spec requirement would actually prevent any of these
performance traps.
Hope this helps,
-kg
On Fri, Jul 12, 2013 at 10:59 AM, Brendan Eich bren...@mozilla.com wrote:
Allen Wirfs-Brock wrote:
you might consider ticketing performance bugs against the various
implementations.
Right, and at most summarize with links to those issues for es-discuss.
This is not a language issue, rather a quality of implementation one.
/be
Allen
On Jul 10, 2013, at 9:16 AM, Claus Reinke wrote:
The TypeScript project tries to emulate arrow functions through the
_this = this pattern and keeps running into corner cases where a
semi-naïve renaming is not sufficient.
I have been trying to suggest using .bind to emulate arrow functions
instead, but the counter-arguments are (a) .bind might not be available
(supporting pre-ES5 targets) and (b) .bind is slow.
The polyfill isn't the problem, but I'm a bit shocked every time
someone reminds me of the performance hit for using .bind. Given
that a bound function has strictly more info than an unbound one,
I wouldn't expect that (I expected a bound function to be roughly
the same as an unbound function that does not use this). Unless
there is no special casing for the just-add-this case, and .bind is
always treated as a non-standard (meta-level) call.
While playing with test-code, I also found that v8 does a lot better
than other engines when using an .apply-based .bind emulation.
Can anyone explain what is going on with .bind, .apply and the
performance hits?
The TypeScript issue is
https://typescript.codeplex.**com/workitem/1322https://typescript.codeplex.com/workitem/1322.
My test code (*) is attached there as bind-for-arrows.html.
Claus
http://clausreinke.github.com/
(*) I also tried to make a jsperf test case, but the way jsperf
runs the loop seems to prevent the optimization that makes
v8 look good for the .apply-based bind.
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: new Symbol(obj)
I would welcome (with fanfare and parades) a new Symbol(obj) that worked
for strings and integers. Such is not possible using the WeakMap shim
(you'd have to detect the type of the value and have multiple dictionaries,
or something, and you'd leak the symbols forever...)
Of course, what that means is I'm asking for weakly cached symbols with
referential identity, which means it would allow detecting garbage
collections, so this is probably around the point where people chime in and
say it's not possible. Oh well. :(
On Fri, Jul 12, 2013 at 12:42 PM, Jeremy Martin jmar...@gmail.com wrote:
Good point, that's definitely a usable solution (also a better
representation of what I was attempting to describe).
I'd still be interested in a less-verbose/more-efficient approach using
the Symbol constructor, but it may not be a common enough scenario to
justify it when a workaround does exist.
On Fri, Jul 12, 2013 at 3:32 PM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Jul 12, 2013, at 12:14 PM, Jeremy Martin wrote:
In brief: allow Symbol's to be constructed with a single parameter, with
the following behavior:
var obj = {};
undefined
new Symbol({}) === new Symbol({})
false
new Symbol(obj) === new Symbol(obj)
true
You can use a WeakMap to build your own object-selected Symbol factory:
let known = new WeakMap;
function ObjSymFactory(obj) {
//handle obj === undefined however you want
let sym = known.get(obj);
If (!sym) {
sym = new Symbol;
known.set(obj,sym);
}
return sym;
}
Allen
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
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: Proposal: new Symbol(obj)
My expectation would be that...
(a === b) === (new Symbol(a) === new Symbol(b))
I.e., `new Symbol(a) === new Symbol(b)` iff `a === b`. This satisfies the
strings/integers scenario, but, of course, fails your WeakMap garbage
collection semantics. You need WeakSymbolMaps (+ this proposal) :)
On Fri, Jul 12, 2013 at 4:15 PM, K. Gadd k...@luminance.org wrote:
I would welcome (with fanfare and parades) a new Symbol(obj) that worked
for strings and integers. Such is not possible using the WeakMap shim
(you'd have to detect the type of the value and have multiple dictionaries,
or something, and you'd leak the symbols forever...)
Of course, what that means is I'm asking for weakly cached symbols with
referential identity, which means it would allow detecting garbage
collections, so this is probably around the point where people chime in and
say it's not possible. Oh well. :(
On Fri, Jul 12, 2013 at 12:42 PM, Jeremy Martin jmar...@gmail.com wrote:
Good point, that's definitely a usable solution (also a better
representation of what I was attempting to describe).
I'd still be interested in a less-verbose/more-efficient approach using
the Symbol constructor, but it may not be a common enough scenario to
justify it when a workaround does exist.
On Fri, Jul 12, 2013 at 3:32 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Jul 12, 2013, at 12:14 PM, Jeremy Martin wrote:
In brief: allow Symbol's to be constructed with a single parameter, with
the following behavior:
var obj = {};
undefined
new Symbol({}) === new Symbol({})
false
new Symbol(obj) === new Symbol(obj)
true
You can use a WeakMap to build your own object-selected Symbol factory:
let known = new WeakMap;
function ObjSymFactory(obj) {
//handle obj === undefined however you want
let sym = known.get(obj);
If (!sym) {
sym = new Symbol;
known.set(obj,sym);
}
return sym;
}
Allen
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: JS Ctypes
for JS Ctypes I meant binary data, as written in the Brendan link I've posted at the beginning, and the part I've played a while ago: http://webreflection.blogspot.com/2011/09/introduction-to-js-ctypes.html It looks like that part, the binary data, and structs, will be in ES6 so ... good news, and looking forward to play with it. br On Fri, Jul 12, 2013 at 11:01 AM, Brendan Eich bren...@mozilla.com wrote: JSCTypes is unsafe, it won't be standardized and we restrict access to Firefox add-ons and chrome (privileged UX implementation) code. Binary data and value objects cover the fast typed structs/primitives. Unsafe FFI is a different issue and should not be mixed up with structs and scalar/SIMD-vector types. It's also not awesome because unsafe. /be Andrea Giammarchi wrote: I wonder if there is any interest/plan/scheduled TC39 slot about JS Ctypes, mentioned by [Brendan Eich in his famous TXJS talk]( https://brendaneich.com/**2011/08/my-txjs-talk-twitter-**remix/https://brendaneich.com/2011/08/my-txjs-talk-twitter-remix/) but never again discussed in this ml. Seeing `asm.js` passing through all usual procedures before `JS Ctypes` I wonder if the latter one is still a thing or it will be abandoned (or it has already been abandoned) Not only other JS engines do not expose these nice and potentially ultra fast typed structs/primitives, when I've benchmarked them a while ago somebody mentioned these are not even JITed in any *Monkey engine. Thanks for any news about this once awesome idea. Best Regards __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why is .bind so slow?
In the future wouldn't using a Function Proxy be potentially much faster?
On Fri, Jul 12, 2013 at 1:12 PM, K. Gadd k...@luminance.org wrote:
I've had some back and forth with v8 devs about this since it affects my
compiler. I believe they already have open issues about it but I don't know
the bug #s.
In general, the problem seems to be that Function.bind creates functions
that have different type information from normal functions you wrote in
pure JS; they're 'special' native functions in the same fashion as say, a
DOM API:
document.createElement
function createElement() { [native code] }
function f () {}
f
function f() {}
f.bind(null)
function () { [native code] }
This is important because v8 tries to gather information about callees at
various call sites. Having a mix of these special and non-special functions
means that the JIT is not able to make safe optimizations based on all the
callers being the same type.
IIRC there are also some other problems specific to v8, like it only being
able to optimize Function.apply and Function.call if the .apply/.call
methods are the implementations used for pure-JS functions (so bind breaks
those too).
I can't comment on why it's slow in SpiderMonkey (I've never asked... I
should file a bug) but it is indeed the case that f.bind(null) produces a
'native code' function in SpiderMonkey, so I expect some of the same
optimization consequences apply.
I also expect that it is much harder for v8 and spidermonkey to inline a
function that contains native code, if not entirely impossible.
All of these problems, as I understand them, are completely fixable. It
might be as simple as making bind return a pure-JS function instead of a
native function. This is supported by the fact that a pure-JS polyfill for
.bind is usually faster in my tests. In general VM authors are much more
helpful when shown real world applications affected by these issues, based
on my experience. They tend to ignore jsperf microbenchmarks, etc.
I don't know that this could be addressed at all from a specification
perspective. The only thing I can think of would be specifying that the
result of Function.bind should somehow be indistinguishable from a
hand-written JS function (no 'native code' in tostring, etc) but I don't
think that sort of spec requirement would actually prevent any of these
performance traps.
Hope this helps,
-kg
On Fri, Jul 12, 2013 at 10:59 AM, Brendan Eich bren...@mozilla.comwrote:
Allen Wirfs-Brock wrote:
you might consider ticketing performance bugs against the various
implementations.
Right, and at most summarize with links to those issues for es-discuss.
This is not a language issue, rather a quality of implementation one.
/be
Allen
On Jul 10, 2013, at 9:16 AM, Claus Reinke wrote:
The TypeScript project tries to emulate arrow functions through the
_this = this pattern and keeps running into corner cases where a
semi-naïve renaming is not sufficient.
I have been trying to suggest using .bind to emulate arrow functions
instead, but the counter-arguments are (a) .bind might not be available
(supporting pre-ES5 targets) and (b) .bind is slow.
The polyfill isn't the problem, but I'm a bit shocked every time
someone reminds me of the performance hit for using .bind. Given
that a bound function has strictly more info than an unbound one,
I wouldn't expect that (I expected a bound function to be roughly
the same as an unbound function that does not use this). Unless
there is no special casing for the just-add-this case, and .bind is
always treated as a non-standard (meta-level) call.
While playing with test-code, I also found that v8 does a lot better
than other engines when using an .apply-based .bind emulation.
Can anyone explain what is going on with .bind, .apply and the
performance hits?
The TypeScript issue is
https://typescript.codeplex.**com/workitem/1322https://typescript.codeplex.com/workitem/1322.
My test code (*) is attached there as bind-for-arrows.html.
Claus
http://clausreinke.github.com/
(*) I also tried to make a jsperf test case, but the way jsperf
runs the loop seems to prevent the optimization that makes
v8 look good for the .apply-based bind.
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
Re: [proposal] Function calls, syntax sugar
On Fri, Jul 12, 2013 at 1:42 PM, Andrew Fedoniouk n...@terrainformatica.com
wrote:
On Fri, Jul 12, 2013 at 6:45 AM, Rick Waldron waldron.r...@gmail.com
wrote:
On Fri, Jul 12, 2013 at 12:22 AM, Andrew Fedoniouk
n...@terrainformatica.com wrote:
Quite often I see constructions like this:
foo({one:1,two:2});
so call of function with single parameter - object literal.
Idiom named Poor man named arguments passing
Idea is to extend existing JS/ES syntax calls to support
simple form of the call above:
foo {one:1,two:2 };
Semi-formally that syntax looks like:
function-call:
name-token '(' parameter-list ')' // existing form
name-token object-literal // proposal
Given:
function foo(){ return 1; }
This is a valid function call:
foo
()
// 1;
But this is valid, too (though, not a function call):
foo -- identifier
{} -- empty block
// function foo() { return 1; }
This construction
foo {};
is an equivalent of:
foo({});
but not
foo();
Right, I get that... but what I'm telling you is that your proposal doesn't
work:
foo {}
Same as
foo({})
So, that means:
foo
{}
should be the same as
foo
({})
...Because this is a valid function call.
But it's not the same and cannot be defined as the same, because ASI put a
semi colon at the end of |foo| and {} is a valid empty block. Changing this
would surely be web breaking.
Rick
To call function with empty param list you still need empty '('')'
brackets.
Also, I could be wrong, but wouldn't there need to be a way to
disambiguate
UnaryExpression?
typeof foo { one: 1, two: 2 }
Maybe this is not an issue, or easily dealt with?
This is not an issue. Parsed exactly the same as:
typeof foo({ one: 1, two: 2 })
Right, but again:
function foo() {return 1;}
typeof foo
({})
number
...Because this is the same as
typeof foo({})
So you need a [no LineTerminator here], which unnecessarily complicates:
CallExpression Arguments
CallExpression[no LineTerminator here]ObjectLiteral
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [proposal] Function calls, syntax sugar
On Fri, Jul 12, 2013 at 2:08 PM, Andrew Fedoniouk n...@terrainformatica.com
wrote:
On Fri, Jul 12, 2013 at 7:02 AM, Rick Waldron waldron.r...@gmail.com
wrote:
On Fri, Jul 12, 2013 at 12:22 AM, Andrew Fedoniouk
n...@terrainformatica.com wrote:
Quite often I see constructions like this:
foo({one:1,two:2});
so call of function with single parameter - object literal.
Idiom named Poor man named arguments passing
Idea is to extend existing JS/ES syntax calls to support
simple form of the call above:
foo {one:1,two:2 };
Semi-formally that syntax looks like:
function-call:
name-token '(' parameter-list ')' // existing form
name-token object-literal // proposal
Existing grammar:
CallExpression Arguments
Arguments :
( )
( ArgumentList )
To add ObjectLiteral, at very least the grammar would need to have a
NoLineTerminator between CallExpression and Arguments, which breaks
extant
code.
Yes, NoLineTerminator is required for non-strict mode (that ugly
semicolon elision
strikes again)
Even in non-strict mode this code:
function foo(obj) { return 1; }
var c = foo { one:1 };
produces parsing error before the '{' - semicolon required.
Of course it does, but again, you're ignoring my point about ASI.
Invocation parens (and arguments list) are allowed to be on the a following
line:
function foo(value) { return value; }
foo
(hi!)
// hi!;
And again, the opening and closing curly brace synatx that you think is an
ObjectLiteral becomes a valid Block on the next line (because invocation
parens and argument lists CAN be on the next line):
function foo(obj) { return 1; }
var c = foo
{ one:1 }; -- valid block, containing a LabelStatement
// 1
c;
// function foo(obj) { return 1; }
The same kind of error is in this case too:
function foo(p1,p2) { return 1; }
var c = foo 1,2;
Still the same reason I've said over several responses.
function foo(p1,p2) { return 1; }
var c = foo
1,2;
// 2
c;
// function foo(obj) { return 1; }
So that syntax change will be backward compatible - it will
not change semantic of existing valid code.
Contrary to the evidence I've provided several times in several messages?
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Why is .bind so slow?
Thanks, kg! Your message represents the kind of discussion/information I was hoping for. If your hunch as to the reason is correct, it would seem an easy target for optimization. Partially and efficiently emulating arrow functions in ES6 transpilers should be a strong argument in favor, though not the only one (eg bind keeps coming up as a recommendation when using class methods as callback parameters, etc.). For those interested, I've put my (micro) bench in a gist: https://gist.github.com/clausreinke/5987876 (note in particular the performance difference between .bind and an .apply-based polyfill; other engines do worse) I used es-discuss for this thread because: - all engines are slow on .bind, so it is likely a general issue - all engines are slow on .bind, so recommending .bind as freely as I (and several people on this list) used to do does not seem realistic; that puts a serious dent in the usability of this part of the spec - even if that issue may turn out not to be spec-related, this is the only list I know of where I can reach all engine developers and es language gurus at once. If this kind of es implementation/performance discussion is not welcome here, a dedicated cross-engine list for such topics would be nice. Would only work if all engines had developers listening in. As long as there isn't enough traffic to warrant a dedicated list, I (as one of the list owners there) welcome such threads on js-tools http://groups.google.com/group/js-tools/about (on the basis that engines are our most fundamental js tools;-) Please let me know where to raise such cross-engine threads in future. Claus I've had some back and forth with v8 devs about this since it affects my compiler. I believe they already have open issues about it but I don't know the bug #s. In general, the problem seems to be that Function.bind creates functions that have different type information from normal functions you wrote in pure JS; they're 'special' native functions in the same fashion as say, a DOM API: ... ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Questions on clz and toInteger
On Jul 12, 2013, at 1:48 PM, Mark S. Miller wrote:
On Fri, Jul 12, 2013 at 11:00 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Fri, Jul 12, 2013 at 10:48 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
In other words you want to define Number.isInteger to return true only if
it's argument is an integer number in the range -(2^53-1)..2^53-1
That's a useful test and a plausible definition of Number.isInteger but it
will also probably be surprising to programmers who are familiar with the
esoterics of IEEE floats.
On the other hand, people (like me) who just want to be able to tell
when something is a freaking integer will be better served by these
semantics. ^_^
I fully agree. It will also help some programmers avoid the mistake I made --
of including 2**53 in their own home-rolled test.
If we went that direction what should Number.toInteger do for values
outside that range?
For consistency, it should wrap mod 2**53 of course.
Just kidding. I have no coherent opinion yet of what it should do. What are
the use cases we imagine toInteger may be useful for?
Well in the spec. the equivalent operation is used in various algorithms that
access collections that are Uint32 length limited. For example, accessing
elements of TypedArrays
For example, checking a a typed array index against the length of the array:
function get(ta, index) {
let intIndex = Number.toInteger(index); //why isn't this
index.toInteger(); ??
let len = ta.length;
if (!Number.isFinite(len)) return undefined
if (intIndex = len) return undefined;
if (intIndex len) return undefined;
return ta[intIndex];
}
Note that this is a situation where it would be most convenient if toInteger
just passed through infinities in which case the explicit isFinite test could
be eliminated.
Also, in the above, I'm assuming the NaN converts to 0.
Allen___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Why is .bind so slow?
On Jul 12, 2013, at 1:55 PM, Matthew Robb wrote: In the future wouldn't using a Function Proxy be potentially much faster? It seems highly unlikely that any use of Proxy will be faster than a rough equivalent using an ordinary object. I expect proxies to be much harder for implementations to optimized than ordinary objects. Looking at it another way, if implementation haven't found it straightforward to optimize ES5 bound functions why would you expect that would have an easier time with Proxys? Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Questions on clz and toInteger
On 07/12/2013 10:27 AM, Tab Atkins Jr. wrote: And, because of what we discussed in the recent thread... Number.isInteger(Math.pow(2,53)-1) == true Number.isInteger(Math.pow(2,53)) == false I need to comment in the other thread again and push back against what people have said there, but that thread's issues aside entirely, this is very very wrong. 2**53 is an integer. That there are multiple mathematical integer values that, when converted to IEEE-754 format, are equal to 2**53 is irrelevant. An integer value, that operations claim is not an integer, is very very wat. Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [proposal] Function calls, syntax sugar
On Fri, Jul 12, 2013 at 2:06 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Fri, Jul 12, 2013 at 1:42 PM, Andrew Fedoniouk
n...@terrainformatica.com wrote:
...
This construction
foo {};
is an equivalent of:
foo({});
but not
foo();
Right, I get that... but what I'm telling you is that your proposal doesn't
work:
foo {}
Same as
foo({})
So, that means:
foo
{}
should be the same as
foo
({})
...Because this is a valid function call.
But it's not the same and cannot be defined as the same, because ASI put a
semi colon at the end of |foo| and {} is a valid empty block. Changing this
would surely be web breaking.
Seems like I am not getting that famous ASI thing.
I do not understand why here:
foo
(exp);
there is no semicolon injected. It rather should be this:
foo;
(exp);
if that ASI thing has any traces of logic behind.
BTW: what about use strict ? Does it govern ASI parsing rules?
If not then why?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Questions on clz and toInteger
On Jul 12, 2013, at 3:54 PM, Jeff Walden wrote: On 07/12/2013 10:27 AM, Tab Atkins Jr. wrote: And, because of what we discussed in the recent thread... Number.isInteger(Math.pow(2,53)-1) == true Number.isInteger(Math.pow(2,53)) == false I need to comment in the other thread again and push back against what people have said there, but that thread's issues aside entirely, this is very very wrong. 2**53 is an integer. That there are multiple mathematical integer values that, when converted to IEEE-754 format, are equal to 2**53 is irrelevant. An integer value, that operations claim is not an integer, is very very wat. are you suggesting that if we want such an function, it should be named something else, such as isExactInteger, isPreciseInteger, isUnambiguousInteger, etc? Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why is .bind so slow?
If a function proxy is just forwarding an operation through an intermediary (the proxy and it's call trap) to another function it sounds very similar to a regularly wrapped/bound js function. So what I am saying is if browsers implemented bind using a proxy instead of the special native functions it would be theoretically faster. On Fri, Jul 12, 2013 at 2:54 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Jul 12, 2013, at 1:55 PM, Matthew Robb wrote: In the future wouldn't using a Function Proxy be potentially much faster? It seems highly unlikely that any use of Proxy will be faster than a rough equivalent using an ordinary object. I expect proxies to be much harder for implementations to optimized than ordinary objects. Looking at it another way, if implementation haven't found it straightforward to optimize ES5 bound functions why would you expect that would have an easier time with Proxys? Allen -- - Matthew Robb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: more numeric constants please (especially EPSILON)
On 07/09/2013 06:49 PM, Mark S. Miller wrote:
Because Nat includes 2**53, this code actually fails to enforce conservation
of currency!!
The problem isn't that Nat includes 2**53. It's that you're performing an
operation that may compute an inexact value, then you're treating that inexact
value *as if it were exact*. You should be testing *before* performing any
operation that might compute an inexact value. Or, you should be rejecting
values which might be rounded from an inexact value. Which would mean your
MAX_NAT test should instead be
if (allegedNum = MAX_NAT) { throw new RangeError('too big'); }
But really, Nat seems like the wrong concept to me. Even if you correct it as
above, it's only correctly usable if it is applied after *every* floating point
operation. If you have |a + b|, you can correctly apply a corrected Nat to
that. But if you have |a + b + c| or |a + b - c| or any more floating-point
operations than a single operation, Nat can't be correctly applied. Corrected
Nat as-is gives a false sense of security, by implying that you can apply it to
a calculation and it'll do the right thing, when really it'll only do so if the
value you're passing in is the result of no more than a single computation.
Jeff
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: more numeric constants please (especially EPSILON)
On Fri, Jul 12, 2013 at 4:07 PM, Jeff Walden jwalden...@mit.edu wrote:
On 07/09/2013 06:49 PM, Mark S. Miller wrote:
Because Nat includes 2**53, this code actually fails to enforce conservation
of currency!!
The problem isn't that Nat includes 2**53. It's that you're performing an
operation that may compute an inexact value, then you're treating that
inexact value *as if it were exact*. You should be testing *before*
performing any operation that might compute an inexact value. Or, you should
be rejecting values which might be rounded from an inexact value. Which
would mean your MAX_NAT test should instead be
if (allegedNum = MAX_NAT) { throw new RangeError('too big'); }
But really, Nat seems like the wrong concept to me. Even if you correct it
as above, it's only correctly usable if it is applied after *every* floating
point operation. If you have |a + b|, you can correctly apply a corrected
Nat to that. But if you have |a + b + c| or |a + b - c| or any more
floating-point operations than a single operation, Nat can't be correctly
applied. Corrected Nat as-is gives a false sense of security, by implying
that you can apply it to a calculation and it'll do the right thing, when
really it'll only do so if the value you're passing in is the result of no
more than a single computation.
Mark's Nat() function *does* throw if the input isn't an
exactly-representable number.
~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Questions on clz and toInteger
On Fri, Jul 12, 2013 at 3:54 PM, Jeff Walden jwalden...@mit.edu wrote: On 07/12/2013 10:27 AM, Tab Atkins Jr. wrote: And, because of what we discussed in the recent thread... Number.isInteger(Math.pow(2,53)-1) == true Number.isInteger(Math.pow(2,53)) == false I need to comment in the other thread again and push back against what people have said there, but that thread's issues aside entirely, this is very very wrong. 2**53 is an integer. That there are multiple mathematical integer values that, when converted to IEEE-754 format, are equal to 2**53 is irrelevant. An integer value, that operations claim is not an integer, is very very wat. 2^53 + 2 is also an integer, but it's clearly outside the range of *exactly-representable integers*, where each integer has one and only one representation. You can't tell if the number you got is actually 2^53+2 or not - it might have been input as 2^53+3, or 2^53+.1, or any number of other starting inputs. If you agree with that reasoning that 2^53+2 should return false from isInteger(), then you must agree that 2^53 should also return false. If you don't agree with that reasoning, then I suppose you'd argue that *all* numbers 2^53 should return true, since they're all forced into being represented as integers? If neither of these describe your position, could you explain your position in more detail? ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Questions on clz and toInteger
On 07/12/2013 04:03 PM, Allen Wirfs-Brock wrote:
are you suggesting that if we want such an function, it should be named
something else, such as isExactInteger, isPreciseInteger,
isUnambiguousInteger, etc?
Possibly, but I don't think so. Whether a value is exact or precise is a
function not of the value itself, but of how it was computed. Math.pow(2, 53)
computed that way is an exact value. Math.pow(2, 53) - 1 + 2 is (in IEEE-754
terms) the same value. But it is not exact, because it derived from an inexact
computation. It all depends how you got the value you're passing in.
isUnambiguousInteger is in a different league from exact/precise. Assuming a
definition like so, it might be reasonable:
function isUnambiguousInteger(n)
{
if ((n % 1) !== 0)
return false;
return Math.abs(n) Math.pow(2, 53);
}
I'm not sure whether it would be useful enough to carry weight, tho, given it
has fairly esoteric use cases. And anyone asking these sorts of questions
really needs to know the IEEE-754 design well enough to understand how/why
things go wrong, well enough that they could code it themselves. The existence
of such a method doesn't make it any more likely that they will understand
these details.
Jeff
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [proposal] Function calls, syntax sugar
On Fri, Jul 12, 2013 at 3:55 PM, Andrew Fedoniouk n...@terrainformatica.com wrote: Seems like I am not getting that famous ASI thing. I do not understand why here: foo (exp); there is no semicolon injected. It rather should be this: foo; (exp); if that ASI thing has any traces of logic behind. It has a very simple logic, just not the one you're assuming. You're probably thinking that the rule is if a line doesn't end in a semicolon, and you can insert one without causing this line or the next to have a parse error, do so. The actual rule is if a line doesn't end in a semicolon, attempt to join it with the following line. If that causes a syntax error, insert a semicolon and try again. In other words, ASI only happens when a semicolon is *required*, not when one is *possible*. BTW: what about use strict ? Does it govern ASI parsing rules? If not then why? No, strict mode has no effect on ASI. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Questions on clz and toInteger
On 07/12/2013 04:13 PM, Tab Atkins Jr. wrote: If you don't agree with that reasoning, then I suppose you'd argue that *all* numbers 2^53 should return true, since they're all forced into being represented as integers? All numbers = 2**53 except Infinity, yes. I think isInteger implies the mathematical concept, with the only addition that it should pass -0. And while it would somewhat unfortunately diverge from the ToInteger spec operation, toInteger should imply the mathematical concept as well, and only produce values that are mathematical integers. (toInteger should probably convert -0 to -0 for consistency with isInteger on -0, but probably I could go either way here.) Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: more numeric constants please (especially EPSILON)
On 07/12/2013 04:09 PM, Tab Atkins Jr. wrote: Mark's Nat() function *does* throw if the input isn't an exactly-representable number. Yes. I'm arguing that's not helpful when you can compute an exactly-representable number, that is the result of an inexact calculation, like |Math.pow(2, 53) + 1 - 4|. The JS result of that calculation is an exactly-representable number. But the mathematical result of that computation is not the same number. Nat treats the number passed to it as if it were a calculation's exact result, when it may not be. Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Questions on clz and toInteger
On Jul 12, 2013, at 4:18 PM, Jeff Walden wrote:
On 07/12/2013 04:03 PM, Allen Wirfs-Brock wrote:
are you suggesting that if we want such an function, it should be named
something else, such as isExactInteger, isPreciseInteger,
isUnambiguousInteger, etc?
Possibly, but I don't think so. Whether a value is exact or precise is a
function not of the value itself, but of how it was computed. Math.pow(2,
53) computed that way is an exact value. Math.pow(2, 53) - 1 + 2 is (in
IEEE-754 terms) the same value. But it is not exact, because it derived from
an inexact computation. It all depends how you got the value you're passing
in.
isUnambiguousInteger is in a different league from exact/precise. Assuming
a definition like so, it might be reasonable:
function isUnambiguousInteger(n)
{
if ((n % 1) !== 0)
return false;
return Math.abs(n) Math.pow(2, 53);
}
I'm not sure whether it would be useful enough to carry weight, tho, given it
has fairly esoteric use cases. And anyone asking these sorts of questions
really needs to know the IEEE-754 design well enough to understand how/why
things go wrong, well enough that they could code it themselves. The
existence of such a method doesn't make it any more likely that they will
understand these details.
So the other thread was a discussion concerning the appropriate value of
Number.MAX_INTEGER. Do you think it should be 2^53-1, or 2^53, or the same
thing as Math..MAX_VALUE.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Questions on clz and toInteger
On 13/07/2013, at 01:24, Jeff Walden wrote: On 07/12/2013 04:13 PM, Tab Atkins Jr. wrote: If you don't agree with that reasoning, then I suppose you'd argue that *all* numbers 2^53 should return true, since they're all forced into being represented as integers? All numbers = 2**53 except Infinity, yes. I think isInteger implies the mathematical concept, with the only addition that it should pass -0. And while it would somewhat unfortunately diverge from the ToInteger spec operation, toInteger should imply the mathematical concept as well, and only produce values that are mathematical integers. (toInteger should probably convert -0 to -0 for consistency with isInteger on -0, but probably I could go either way here.) Everything from Math.pow(2,52) to Math.pow(2,53) are integers (if represented as IEE-754 doubles), because there's no bit left to represent Math.pow(2,-1): Math.pow(2,52) 4503599627370496 Math.pow(2,52).toString(2) 1 Math.pow(2,52).toString(2).length 53 (Math.pow(2,52)-1).toString(2) (Math.pow(2,52)-1).toString(2).length 52 Math.pow(2,52)-0.5 4503599627370495.5 Math.pow(2,52)+0.5 4503599627370496 -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Questions on clz and toInteger
On 07/12/2013 04:32 PM, Allen Wirfs-Brock wrote: So the other thread was a discussion concerning the appropriate value of Number.MAX_INTEGER. Do you think it should be 2^53-1, or 2^53, or the same thing as Math..MAX_VALUE. Number.MAX_INTEGER should be 2**53. People who want 2**53 - 1 (and there are roughly reasonable uses for it as discussed in that thread, if enough care is taken) can use as the relevant operator when comparing. In contrast, if the value were 2**53 - 1, people who want the 2**53 value can't simply use a different operator. I haven't kept up enough with this list to know what Math.MAX_VALUE is, and it's not in the latest draft I have -- unless you meant Number.MAX_VALUE? If you meant that, Number.MAX_INTEGER should definitely be different from Number.MAX_VALUE. Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Questions on clz and toInteger
On Jul 12, 2013, at 4:39 PM, Jeff Walden wrote: On 07/12/2013 04:32 PM, Allen Wirfs-Brock wrote: So the other thread was a discussion concerning the appropriate value of Number.MAX_INTEGER. Do you think it should be 2^53-1, or 2^53, or the same thing as Math..MAX_VALUE. Number.MAX_INTEGER should be 2**53. People who want 2**53 - 1 (and there are roughly reasonable uses for it as discussed in that thread, if enough care is taken) can use as the relevant operator when comparing. In contrast, if the value were 2**53 - 1, people who want the 2**53 value can't simply use a different operator. Number.MAX_INTEGER+1 ?? I haven't kept up enough with this list to know what Math.MAX_VALUE is, and it's not in the latest draft I have -- unless you meant Number.MAX_VALUE? If you meant that, Number.MAX_INTEGER should definitely be different from Number.MAX_VALUE. Sorry, I meant Number.MAX_VALUE. So you seem to be saying that that Number.isInteger(MAX_VALUE) should be true, but that Number.MAX_VALUE Number.MAX_INTEGER is also true because for isInteger you using the mathematical definition of Integer but for MAX_INTEGER you are using some other definition of INTEGER. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why is .bind so slow?
just to add some extra info to this discussion, lo-dash does some crazy thing to optimize at its best bound functions. `/\bthis\b/.test(Function.prototype.toString.call(callback))` or something similar to check if the function needs to use call/apply at all, together with the number of arguments, and some other analysis to optimize all further calls to the bound function. While I believe that's a bit extreme, I have to admit performance gain is huge so maybe some trick used in lo-dash could be used internally too ? Like different specialized bound version? Most common use case is still a method bound to the object itself in order to don't loose the context on some event call. my 2 cents On Fri, Jul 12, 2013 at 4:04 PM, Matthew Robb matthewwr...@gmail.comwrote: If a function proxy is just forwarding an operation through an intermediary (the proxy and it's call trap) to another function it sounds very similar to a regularly wrapped/bound js function. So what I am saying is if browsers implemented bind using a proxy instead of the special native functions it would be theoretically faster. On Fri, Jul 12, 2013 at 2:54 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Jul 12, 2013, at 1:55 PM, Matthew Robb wrote: In the future wouldn't using a Function Proxy be potentially much faster? It seems highly unlikely that any use of Proxy will be faster than a rough equivalent using an ordinary object. I expect proxies to be much harder for implementations to optimized than ordinary objects. Looking at it another way, if implementation haven't found it straightforward to optimize ES5 bound functions why would you expect that would have an easier time with Proxys? Allen -- - Matthew Robb ___ 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: Why is .bind so slow?
one more thing ... I believe this will impact arrow function too since is basically bound callbacks all over the place (or at least this is how I believe it will be transpiled) On Fri, Jul 12, 2013 at 4:57 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: just to add some extra info to this discussion, lo-dash does some crazy thing to optimize at its best bound functions. `/\bthis\b/.test(Function.prototype.toString.call(callback))` or something similar to check if the function needs to use call/apply at all, together with the number of arguments, and some other analysis to optimize all further calls to the bound function. While I believe that's a bit extreme, I have to admit performance gain is huge so maybe some trick used in lo-dash could be used internally too ? Like different specialized bound version? Most common use case is still a method bound to the object itself in order to don't loose the context on some event call. my 2 cents On Fri, Jul 12, 2013 at 4:04 PM, Matthew Robb matthewwr...@gmail.comwrote: If a function proxy is just forwarding an operation through an intermediary (the proxy and it's call trap) to another function it sounds very similar to a regularly wrapped/bound js function. So what I am saying is if browsers implemented bind using a proxy instead of the special native functions it would be theoretically faster. On Fri, Jul 12, 2013 at 2:54 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jul 12, 2013, at 1:55 PM, Matthew Robb wrote: In the future wouldn't using a Function Proxy be potentially much faster? It seems highly unlikely that any use of Proxy will be faster than a rough equivalent using an ordinary object. I expect proxies to be much harder for implementations to optimized than ordinary objects. Looking at it another way, if implementation haven't found it straightforward to optimize ES5 bound functions why would you expect that would have an easier time with Proxys? Allen -- - Matthew Robb ___ 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: Questions on clz and toInteger
On 07/12/2013 04:56 PM, Allen Wirfs-Brock wrote: So you seem to be saying that that Number.isInteger(MAX_VALUE) should be true, but that Number.MAX_VALUE Number.MAX_INTEGER is also true because for isInteger you using the mathematical definition of Integer but for MAX_INTEGER you are using some other definition of INTEGER. I think so. Although, I am not at all wedded to the MAX_INTEGER name, it's just what was proposed already. :-) Your implied point is well-taken that max integer is a misnomer. MAX_EXACT_INTEGER, perhaps? Maybe? I dunno. There surely must be some API with prior art for a name here, but I can't immediately find it in web searches right now. Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [proposal] Function calls, syntax sugar
On Fri, Jul 12, 2013 at 4:17 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Fri, Jul 12, 2013 at 3:55 PM, Andrew Fedoniouk
n...@terrainformatica.com wrote:
Seems like I am not getting that famous ASI thing.
I do not understand why here:
foo
(exp);
there is no semicolon injected. It rather should be this:
foo;
(exp);
if that ASI thing has any traces of logic behind.
It has a very simple logic, just not the one you're assuming.
You're probably thinking that the rule is if a line doesn't end in a
semicolon, and you can insert one without causing this line or the
next to have a parse error, do so. The actual rule is if a line
doesn't end in a semicolon, attempt to join it with the following
line. If that causes a syntax error, insert a semicolon and try
again.
In other words, ASI only happens when a semicolon is *required*, not
when one is *possible*.
Your hypothesis would be true if not this case:
return
{ a:1 };
Why it injects ';' after the return? This
return { a:1 };
is perfectly valid construction.
BTW: what about use strict ? Does it govern ASI parsing rules?
If not then why?
No, strict mode has no effect on ASI.
Too bad IMO.
--
Andrew Fedoniouk.
http://terrainformatica.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: more numeric constants please (especially EPSILON)
On 07/12/2013 04:53 PM, Mark S. Miller wrote: I would like a better API -- both less likely to be used unsafely and no harder (or not much harder) to use safely. Suggestions? In C++ you'd want MS's SafeInt, or WTF's CheckedInt, with operator overloading and all that jazz. Without operator overloading the best I can think of are functions for every operation, that have to be used, and if you use the raw operators you take your life into your own hands. Definitely not as easy as just doing the math the normal-looking way. I don't see a super-nice way to do this. :-\ Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Questions on clz and toInteger
While I sympathize with the desire to make integer mean mathematical integer, I don't think it's going to work out very well. Nobody actually cares about such functions, and you of course have the WATs of ```js Number.isInteger(9007199254740992.5) === true ``` since the runtime couldn't distinguish this from `9007199254740992`. In practice all this ends up doing is forcing our currently-proposed useful functions/constants to have an exact/EXACT inserted into them. I think it would be easier just to accept that integer in JS does not mean mathematical integer but instead means unambiguously representable integer, since that is operationally the useful definition. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [proposal] Function calls, syntax sugar
On Jul 12, 2013, at 5:09 PM, Andrew Fedoniouk wrote:
Your hypothesis would be true if not this case:
return
{ a:1 };
Why it injects ';' after the return? This
Because, the actual ECMAScript grammar says a new line can't occur between the
'return' keyword and the optional return expression.
http://www.ecma-international.org/ecma-262/5.1/#sec-12.9
You really need to read and understand the relevant portions of the
specification before engaging in this sort of discussion.
http://www.ecma-international.org/ecma-262/5.1/#sec-7.9
Allen___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Questions on clz and toInteger
On 07/12/2013 06:17 PM, Tab Atkins Jr. wrote: On Fri, Jul 12, 2013 at 5:15 PM, Domenic Denicola dome...@domenicdenicola.com wrote: While I sympathize with the desire to make integer mean mathematical integer, I don't think it's going to work out very well. Nobody actually cares about such functions, and you of course have the WATs of ```js Number.isInteger(9007199254740992.5) === true ``` since the runtime couldn't distinguish this from `9007199254740992`. This is what I was trying to point out as a ridiculous possibility in Jeff's idea, except he claimed it's what he actually wanted. ;_; Roughly no one will type something like that. :-) And if the value were the result of an operation that lost precision, there's no way to tell that with an API that tells you if the value was an integer. Indeed, asking if the value is an integer seems a bit of a non sequitur to me, for that concern. Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Questions on clz and toInteger
On Fri, Jul 12, 2013 at 6:39 PM, Jeff Walden jwalden...@mit.edu wrote: On 07/12/2013 06:17 PM, Tab Atkins Jr. wrote: On Fri, Jul 12, 2013 at 5:15 PM, Domenic Denicola dome...@domenicdenicola.com wrote: While I sympathize with the desire to make integer mean mathematical integer, I don't think it's going to work out very well. Nobody actually cares about such functions, and you of course have the WATs of ```js Number.isInteger(9007199254740992.5) === true ``` since the runtime couldn't distinguish this from `9007199254740992`. This is what I was trying to point out as a ridiculous possibility in Jeff's idea, except he claimed it's what he actually wanted. ;_; Roughly no one will type something like that. :-) And if the value were the result of an operation that lost precision, there's no way to tell that with an API that tells you if the value was an integer. Exactly, which is why we can only *accurately* answer for numbers = 2^53-1. Anything larger might have lost precision. Technically, smaller things may lose precision as well - 2^52 + .5 == 2^52. But expecting precision out of decimals is a mugs game anyway. As long as you stick to integers, you can be sure of your precision for = 2^53-1, but as soon as you hit 2^53, you're no longer sure. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Questions on clz and toInteger
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com] Exactly, which is why we can only *accurately* answer for numbers = 2^53-1. Probably a horrible idea in practice, but I feel like the correct answer here is `throw`ing outside that range. It's like asking is Tab's second head blonde or brunette? The only appropriate answer seems to be does not compute. (I think this might be my worst analogy yet. Woohoo!) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
