Re: [module] dynaimic namespace/scope
Excellent point. I had forgotten all about polyfills. You could work around that issue by allowing augmentation of the @std module in some manner...in essence that's what a polyfill does. Your polyfill code would be loaded up first, it would augment the standard module and then your application code would execute with no issues. This would mean the standard module is not consistent with other modules so it's not a proposal I'm putting too much weight on. On Thu, Jul 11, 2013 at 6:26 PM, Brendan Eich bren...@mozilla.com wrote: Brian Di Palma wrote: That would require a tedious preamble for pretty much any bit of code you want to write. You can add an exemption for any code/classes/functions in @std modules. Beyond those cases I see no issue. Object detection is a (if not *the*) successful anti-versioning pattern in JS on the web. It typically depends on global properties that may or may not be present, accessed in the detection condition via window.foo or typeof foo but then bound in the not-detected consequent, and used later, without any object-property base-expression (dot) qualification. Object detection ought to be usable in a module, and IIRC this is another consideration informing the current design. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maps and Sets, goodbye polyfill ?!
// ES6
function* entries(obj){
for (let key in obj) {
yield [key, obj[key]];
}
}
cool, but why do we need that exactly ?
The one suggestion I can make is that generators mean you don't have
to calculate the entire answer up front.
This is well demonstrated by Brandon's code examples. This could be a
nice performance gain under certain circumstances.
// ES3-5 version
function entries(obj){
var keys = [];
var index = 0;
for (keys[index++] in obj);
var total = index;
index = 0;
return {
next: function(){
if (index total) {
var key = keys[index++];
return { done: false, value: [key, obj[key]] }
}
return { done: true };
}
};
}
have you guys read this article ? where it talks about JS people not
thinking about GC and RAM ?
http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
I have read the article, I found it interesting. I was just wondering
if the 'const' keyword would help give JS another small performance
boost.
As Andreas points out the major issue is that JS is highly dynamic,
this can be very useful sometimes but for most code it's not required.
Maybe if you mark everything as const or freeze/seal classes then
maybe JS engines will optimize for that code.
One issue that could help with is memory allocation for JS objects,
maybe that will make it easier to know how much memory to allocate
for a class, or JS object if it's marked as a const. I don't know for
sure as I lack the knowledge, I do know that in ES6 code I will use
const as
my new var.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Maps and Sets, goodbye polyfill ?!
Le 13/07/2013 10:21, Brian Di Palma a écrit : I was just wondering if the 'const' keyword would help give JS another small performance boost. Unlikely. Const can be almost statically inferred (no assignment to a given variable). The almost refers to cases where eval happens. Worst case, if there is no assignment, a variable can be optimistically optimized as const. If the value is changed via eval, then de-optimize (but in practice, eval is rare, so the optimistic optimization will be worth it) As Andreas points out the major issue is that JS is highly dynamic, this can be very useful sometimes but for most code it's not required. Maybe if you mark everything as const or freeze/seal classes then maybe JS engines will optimize for that code. JS engines already optimistically optimize assuming code remains stable (for objects, V8 has hidden classes, SpiderMonkey has the equivalent shape feature) and deoptimizes when the dynamic features are being used. It might be one of the reason why maps are better at being maps than objects (since objects seem to have been optimized for cases where they are stable) David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maps and Sets, goodbye polyfill ?!
OK. So we have reached Peak JavaScript then. If people write JS code without triggering shape changes then the JIT should be able to produce code that can match a JVM? If there was something that I could do as a developer that could help the JIT I would do it. Would ES6 classes not make the creation of shapes a lot easier? From what I understand it takes time to figure out shapes/hidden-classes. Well I'm marking this object as a class, does that help? It would be interesting if engines provided feedback on when we developers break the optimistic optimizations. On Sat, Jul 13, 2013 at 9:43 AM, David Bruant bruan...@gmail.com wrote: Le 13/07/2013 10:21, Brian Di Palma a écrit : I was just wondering if the 'const' keyword would help give JS another small performance boost. Unlikely. Const can be almost statically inferred (no assignment to a given variable). The almost refers to cases where eval happens. Worst case, if there is no assignment, a variable can be optimistically optimized as const. If the value is changed via eval, then de-optimize (but in practice, eval is rare, so the optimistic optimization will be worth it) As Andreas points out the major issue is that JS is highly dynamic, this can be very useful sometimes but for most code it's not required. Maybe if you mark everything as const or freeze/seal classes then maybe JS engines will optimize for that code. JS engines already optimistically optimize assuming code remains stable (for objects, V8 has hidden classes, SpiderMonkey has the equivalent shape feature) and deoptimizes when the dynamic features are being used. It might be one of the reason why maps are better at being maps than objects (since objects seem to have been optimized for cases where they are stable) David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object#extra hazard
I didn't suggest that strings as event type would block anyone,
strings work fine.
I asked for some consideration to be given to also being able to use a
unique object as the type key.
I gave some reasons, copied below.
So in a modern IDE you could click on MY_EVENTS.PERMISSION_UPDATE and
it would display the object which could contain the arguments the
callback is provided with and a place to document the event. It might
also improve minifying/refactoring and searching for occurrences of
the event much easier then if it where a simple string.
None of which are critical but could be handy when dealing with larger
code bases and your event is simply called click.
I'm not too wedded to the idea, but I can imagine that if you are
building applications with hundreds of packages and modules it might
be a safer/easier way to identify instances of your specific event
listeners.
On Thu, Jul 11, 2013 at 11: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.com
wrote:
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
Re: Language Negotiation API
Sorry g, forgot the Cc :-) On Thu, Jul 11, 2013 at 11:52 PM, Zbigniew Braniecki zbranie...@mozilla.com wrote: ... 1) CanonicalizeLanguageTag [1] Because language tags come from developers and users, ability to canonicalize them is crucial to us. ECMA 402 specifies this function and all we need is to expose it in the API I was thinking the same thing recently, at least for CanonicalizeLanguageTag. I was working with a platform that gave me a language tag in non-canonical form, meaning I had to either canonicalize it or rename my language files to match the same non-canonical form. Exposing it as `Intl.canonicalizeLanguageTag(tag)` seems like a good idea. 1.1) CanonicalizeLocaleList [2] That would also be nice to have :) I don't think you could expose CanonicalizeLocaleList directly without altering it to return an array, you'd have to do something similar to step 5 of LookupSupportedLocales. I'm not sure we could change that function in the spec without other abstracts potentially being affected by tainted a Array.prototype, so I guess you'd need to specify a new function. In which case I'm wondering if maybe you'd be better off with `Intl.canonicalizeTags(tags)` which would cover both CanonicalizeLanguageTag() and CanonicalizeLocaleList(). 2) LookupAvailableLocales This function has almost identical heuristic to LookupSupportedLocales [3] with a single difference being in step d). Replace: - If *availableLocale* is not *undefined*, then append *locale* to the end of *subset*. with: - If *availableLocale* is not *undefined*, then append *availableLocale*to the end of *subset*. The reason behind this is that localization frameworks need to choose the available locales that closest match the user preferences. If we used LookupSupportedLocales, we will receive the locales that user requested, not ones that are available on the system. In result on each of those, we'd have to call BestAvailableLocale [4] to receive the tag name that we can pull resources for. You can at least work around this for a single locale with Intl.NumberFormat(tag).resolvedOptions().locale. If you're already using the native localisation APIs, this might not be too much of a hindrance. What you're suggesting would need to be a function property of the constructors, e.g. `Intl.NumberFormat.availableLocalesOf()`. I'm not so sure this approach makes sense, though; wouldn't you still have a problem if your own API provided variant data where the system does not? With that one change, we are actually going to receive the right set of language tags that we can then use to provide best language with fallbacks. Example implementation of this is L20n localization framework [5] which copies Mozilla ECMA 402 code to expose the required functions and uses custom function called prioritizeLocales to build the final locale fallback chain. Comments? Feedback? Next steps? :) Cheers, g. -- Mozilla (http://www.mozilla.org) [1] http://ecma-international.org/ecma-402/1.0/index.html#sec-6.2.3 [2] http://ecma-international.org/ecma-402/1.0/index.html#sec-9.2.1 [3] http://ecma-international.org/ecma-402/1.0/index.html#sec-9.2.6 [4] http://ecma-international.org/ecma-402/1.0/index.html#sec-9.2.2 [5] https://github.com/l20n/l20n.js/blob/master/lib/l20n/intl.js#L431 ___ 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: Language Negotiation API
On Thu, Jul 11, 2013 at 11:52 PM, Zbigniew Braniecki zbraniecki at mozilla.com https://mail.mozilla.org/listinfo/es-discuss / wrote: [...] // /1) CanonicalizeLanguageTag [1] / // Because language tags come from developers and users, ability to // canonicalize them is crucial to us. ECMA 402 specifies this function and // all we need is to expose it in the API // / I was thinking the same thing recently, at least for CanonicalizeLanguageTag. I was working with a platform that gave me a language tag in non-canonical form, meaning I had to either canonicalize it or rename my language files to match the same non-canonical form. Exposing it as `Intl.canonicalizeLanguageTag(tag)` seems like a good idea. Only exposing CanonicalizeLanguageTag does not seem useful to me without having access to IsStructurallyValidLanguageTag. Most likely a combined IsStructurallyValidLanguageTag + CanonicalizeLanguageTag function is necessary/wanted for most use cases. / // 1.1) CanonicalizeLocaleList [2] // // That would also be nice to have :) // / I don't think you could expose CanonicalizeLocaleList directly without altering it to return an array, you'd have to do something similar to step 5 of LookupSupportedLocales. I'm not sure we could change that function in the spec without other abstracts potentially being affected by tainted a Array.prototype, so I guess you'd need to specify a new function. In which case I'm wondering if maybe you'd be better off with `Intl.canonicalizeTags(tags)` which would cover both CanonicalizeLanguageTag() and CanonicalizeLocaleList(). I don't see why you'd need to change CanonicalizeLocaleList at all. Just let it return the internal list as-is, and then define `Intl.canonicalizeLocaleList` like so: Intl.canonicalizeLocaleList(locales): 1. Let canonicalizedLocaleList be the result of CanonicalizeLocaleList(locales). 2. ReturnIfAbrupt(canonicalizedLocaleList). 3. Return CreateArrayFromList(canonicalizedLocaleList). (ReturnIfAbrupt and CreateArrayFromList are defined in ES6 as internal abstract operations.) It also needs to be considered whether the duplicate removal in CanonicalizeLocaleList creates any issues for users of a potential `Intl.canonicalizeLocaleList` or `Intl.canonicalizeTags` function. - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maps and Sets, goodbye polyfill ?!
Le 13/07/2013 11:02, Brian Di Palma a écrit :
OK. So we have reached Peak JavaScript then.
That would be the reason why JS engines don't see 30x (or even 30%)
improvements from a year to another anymore. The JavaScript used on most
websites is fast now. The next boundary for performance is intensive
applications like games. Other than that, room for performance
improvements are to be found at different components like the DOM or
graphics
If people write JS code without triggering shape changes then the JIT
should be able to produce code that can match a JVM?
I would believe so. A bunch of talks from various JS engine implementors
explain that when your code has stable/predictable types, you pretty
much get the performance of... code with stable types. If a + is
always used with integers, it will be JIT-compiled as an integer
addition as it would in C (modulo some guards and overflow issues).
One of these talks http://www.youtube.com/watch?v=UJPdhx5zTaw (there are
plenty others)
If there was something that I could do as a developer that could help
the JIT I would do it.
Usually, the overlap between what JS devs consider good readable code
and what JITs need to optimize is very strong.
From my experience, anytime someone tries being smarter than writing
good code they end up using a fragile optimization (may work in some
engines, but not others, may become a performance issue as the targeted
engine changes over time. For reference, ~25% of a SpiderMonkey changes
each year
https://blog.mozilla.org/dmandelin/2011/11/29/js-development-newsletter-1123-1129/
)
Would ES6 classes not make the creation of shapes a lot easier? From
what I understand it takes time to figure out shapes/hidden-classes.
Well I'm marking this object as a class, does that help?
Implementors will answer better as I'm reaching the limits of my
knowledge, but when you read:
function C(){
this.a = 12;
this.b = azerty;
}
C.prototype = {
...
}
var c = new C();
the shape is pretty clear and class syntax can hardly provide better
insight. Whether current engines already statically analyses functions
like C to get the same sort of info they would use from class syntax, I
don't know.
It would be interesting if engines provided feedback on when we
developers break the optimistic optimizations.
They have given a bunch of talks on the topic at various conferences
already. Search on Youtube if the link I gave above isn't enough ;-)
David
On Sat, Jul 13, 2013 at 9:43 AM, David Bruant bruan...@gmail.com wrote:
Le 13/07/2013 10:21, Brian Di Palma a écrit :
I was just wondering
if the 'const' keyword would help give JS another small performance
boost.
Unlikely. Const can be almost statically inferred (no assignment to a given
variable). The almost refers to cases where eval happens. Worst case, if
there is no assignment, a variable can be optimistically optimized as const.
If the value is changed via eval, then de-optimize (but in practice, eval is
rare, so the optimistic optimization will be worth it)
As Andreas points out the major issue is that JS is highly dynamic,
this can be very useful sometimes but for most code it's not required.
Maybe if you mark everything as const or freeze/seal classes then
maybe JS engines will optimize for that code.
JS engines already optimistically optimize assuming code remains stable (for
objects, V8 has hidden classes, SpiderMonkey has the equivalent shape
feature) and deoptimizes when the dynamic features are being used.
It might be one of the reason why maps are better at being maps than objects
(since objects seem to have been optimized for cases where they are stable)
David
___
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 8:09 PM, Andrew Fedoniouk n...@terrainformatica.com
wrote:
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:
Tab's response is not a hypothesis, it's a generalization of the
specification. ASI rules are defined, unambiguously, in the ECMAScript spec.
return
{ a:1 };
Why it injects ';' after the return? This
return { a:1 };
is perfectly valid construction.
For the same reason I've mentioned several times in this thread: a [no
LineTerminator here], which exists between return and the optional
Expression:
return [no LineTerminator here] Expression (optional);
Rick
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: Language Negotiation API
On Sat, Jul 13, 2013 at 1:05 PM, André Bargull andre.barg...@udo.eduwrote: ... Only exposing CanonicalizeLanguageTag does not seem useful to me without having access to IsStructurallyValidLanguageTag. Most likely a combined IsStructurallyValidLanguageTag + CanonicalizeLanguageTag function is necessary/wanted for most use cases. Hmm. I'm not sure I'd agree it's necessary. IsStructurallyValidLanguageTag makes sense as an abstract function because you need to throw accordingly when an invalid tag is passed to the constructors or methods. However, it's still the developer's responsibility to make sure their tags are valid during the development process. Canonicalisation would still throw an error if the tag is invalid. I don't see why you'd need to change CanonicalizeLocaleList at all. Just let it return the internal list as-is, and then define `Intl.canonicalizeLocaleList` like so: Lists are internal, they aren't part of the ECMAScript language. It makes no sense to return an internal list to ECMAScript code unless you intend to go the whole hog and specify them with a constructor/prototype. It also needs to be considered whether the duplicate removal in CanonicalizeLocaleList creates any issues for users of a potential `Intl.canonicalizeLocaleList` or `Intl.canonicalizeTags` function. Perhaps. Are there any cases you think of where removing duplicates would be a problem? Andy ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why is .bind so slow?
On 07/12/2013 04:59 PM, Andrea Giammarchi wrote:
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)
Sadly, based on the arrow-function patches I've reviewed in SpiderMonkey, I
don't believe this will be necessarily true. Arrow functions and bind-bound
functions are two rather different beasts. Bind-bound functions are
potentially constructible; arrow functions never are. |arguments.callee|
inside a function that's been bound doesn't refer to the bound function -- it
refers to the lexical entity. (That is, |function f() { return
arguments.callee; } f.bind(null)()| is |f|, not |b|.) |arguments.callee|
inside an arrow function -- at least, so long as arrow functions aren't
automatically strict, which decision I would revisit -- refers to the arrow
function. I expect there are other differences I'm not yet aware of, that
would affect having a common implementation of the two concepts.
It seems like a pretty bad idea to me for arrow functions to not be
substantially semantically similar to bind-bound functions, but they are as it
stands now. I wish I had the time to sit down and think through a solid
unification of the two concepts.
Jeff
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Why is .bind so slow?
On 07/12/2013 02:54 PM, Allen Wirfs-Brock wrote: 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? I'm pretty sure no implementation has seriously tried to optimize bound functions, and that that's the major reason for any slowness. I don't think there's anything fundamentally difficult about optimizing bound functions. It's just never been a priority for engines, because it doesn't show up in benchmarks and because the perf bugs for it are less pressing than other perf work is, as bound functions remain underused on the web. Chicken and egg? Sure. In the meantime, while I wouldn't currently question (as a purely pragmatic choice) avoiding bind in highly intensive code where every bit of perf matters, I do think bound functions are fast enough for the vast majority of cases. The overhead of calling a bound function will rarely be the difference between adequate and inadequate performance. Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Language Negotiation API
On 7/13/2013 8:48 PM, Andy Earnshaw wrote: On Sat, Jul 13, 2013 at 1:05 PM, André Bargull andre.barg...@udo.edu mailto:andre.barg...@udo.edu wrote: ... Only exposing CanonicalizeLanguageTag does not seem useful to me without having access to IsStructurallyValidLanguageTag. Most likely a combined IsStructurallyValidLanguageTag + CanonicalizeLanguageTag function is necessary/wanted for most use cases. Hmm. I'm not sure I'd agree it's necessary. IsStructurallyValidLanguageTag makes sense as an abstract function because you need to throw accordingly when an invalid tag is passed to the constructors or methods. However, it's still the developer's responsibility to make sure their tags are valid during the development process. Canonicalisation would still throw an error if the tag is invalid. CanonicalizeLanguageTag isn't even defined for non-structurally valid language tags. That's why I meant a combined IsStructurallyValidLanguageTag + CanonicalizeLanguageTag function is more useful than access to the bare CanonicalizeLanguageTag function. I don't see why you'd need to change CanonicalizeLocaleList at all. Just let it return the internal list as-is, and then define `Intl.canonicalizeLocaleList` like so: Lists are internal, they aren't part of the ECMAScript language. It makes no sense to return an internal list to ECMAScript code unless you intend to go the whole hog and specify them with a constructor/prototype. The internal list structure is not returned to user code instead a possible `Intl.canonicalizeLocaleList` function is a simple wrapper around CanonicalizeLocaleList to perform the necessary conversion from list to array. That's exactly the point of the algorithm steps in my previous mail. It also needs to be considered whether the duplicate removal in CanonicalizeLocaleList creates any issues for users of a potential `Intl.canonicalizeLocaleList` or `Intl.canonicalizeTags` function. Perhaps. Are there any cases you think of where removing duplicates would be a problem? I thought about use cases when a user assumes the i-th element of the output array is the canonicalised value of the i-th element in the input array. I can't tell whether this is a valid use case - I've only implemented ECMA-402, so I know a bit about the spec, but never actually used it in an application... Andy - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why is .bind so slow?
Le 13/07/2013 20:55, Jeff Walden a écrit :
On 07/12/2013 04:59 PM, Andrea Giammarchi wrote:
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)
Sadly, based on the arrow-function patches I've reviewed in SpiderMonkey, I
don't believe this will be necessarily true. Arrow functions and bind-bound
functions are two rather different beasts. Bind-bound functions are
potentially constructible; arrow functions never are. |arguments.callee|
inside a function that's been bound doesn't refer to the bound function -- it
refers to the lexical entity.
One of these things I didn't know (and didn't want to know) about the
language...
(That is, |function f() { return arguments.callee; } f.bind(null)()| is |f|,
not |b|.) |arguments.callee| inside an arrow function -- at least, so long as
arrow functions aren't automatically strict, which decision I would revisit --
refers to the arrow function.
arguments.callee is poisoned is strict mode, so the difference you're
referring only affects non-strict. Should we care? I know I don't.
In general, it should be expected from developers to be in strict mode.
They also shouldn't be using the arguments object...
which decision I would revisit
= I disagree. Implicit strictness at the function level would surprise
people a lot. Maybe break their code when turning a function expression
to an arrow function.
Implicit strictness at the module or class level will already surprise
people a lot.
I expect there are other differences I'm not yet aware of, that would affect
having a common implementation of the two concepts.
Even in strict mode? If there are no differences in strict mode, I don't
think we should care.
It seems like a pretty bad idea to me for arrow functions to not be
substantially semantically similar to bind-bound functions, but they are as it
stands now. I wish I had the time to sit down and think through a solid
unification of the two concepts.
Hopefully by simplifying how bound functions work?
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Why is .bind so slow?
On Jul 13, 2013, at 12:39 PM, Mark S. Miller wrote: Arrow functions, whether strict or non-strict, are not supposed to have their own |arguments| Correct. Implementors should be aware that in the current ES6 draft this is stated in a margin note but not in the actual algorithm for function declaration instantiations (10.5.3) step 11. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why is .bind so slow?
On 07/13/2013 12:56 PM, Allen Wirfs-Brock wrote: On Jul 13, 2013, at 12:39 PM, Mark S. Miller wrote: Arrow functions, whether strict or non-strict, are not supposed to have their own |arguments| Correct. Implementors should be aware that in the current ES6 draft this is stated in a margin note but not in the actual algorithm for function declaration instantiations (10.5.3) step 11. Good to know, thanks. Lack of arguments is sane; last I'd seen in bug commentary was that this wasn't the case. Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [proposal] Function calls, syntax sugar
On Sat, Jul 13, 2013 at 11:16 AM, Rick Waldron waldron.r...@gmail.com wrote:
On Fri, Jul 12, 2013 at 8:09 PM, Andrew Fedoniouk
n...@terrainformatica.com wrote:
On Fri, Jul 12, 2013 at 4:17 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
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:
Tab's response is not a hypothesis, it's a generalization of the
specification. ASI rules are defined, unambiguously, in the ECMAScript spec.
return
{ a:1 };
Why it injects ';' after the return? This
return { a:1 };
is perfectly valid construction.
For the same reason I've mentioned several times in this thread: a [no
LineTerminator here], which exists between return and the optional
Expression:
return [no LineTerminator here] Expression (optional);
OK, what about this definition then
[name] [no LineTerminator here] [literal object declaration];
So this:
foo.bar {
one:1,
two:1
};
will be parse as a method call: foo.bar {one:1,two:1};
And this:
foo.bar
{
one:1,
two:1
};
as in case of 'return' will be parsed with ASI in effect:
foo.bar;
{
one:1,
two:1,
};
Any other discussions about attempts to transform Java/C/C++/D grammar
(where '\n' is just a space) to FORTRAN/BASIC-derived line oriented grammars
(Python/Ruby/Lua/etc) I'll left for off-list conversations.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [proposal] Function calls, syntax sugar
On Sat, Jul 13, 2013 at 10:49 PM, Andrew Fedoniouk
n...@terrainformatica.com wrote:
OK, what about this definition then
[name] [no LineTerminator here] [literal object declaration];
So this:
foo.bar {
one:1,
two:1
};
will be parse as a method call: foo.bar {one:1,two:1};
And this:
foo.bar
{
one:1,
two:1
};
as in case of 'return' will be parsed with ASI in effect:
foo.bar;
{
one:1,
two:1,
};
This is very different to the `return` case in terms of cognitive load.
Associating `return` with ah, no ASI here is much simpler than having to
be on the lookup for ASI exceptions almost everywhere.
Also, `return` at least returns, no matter what. Your proposal would make
the newline relevant in an entirely new way: by making it the difference
between having a statement (the `foo.bar`) that's effect-less in most cases
(i.e., if `foo.bar` isn't an effect-ful getter) followed by a block, and a
function call with the block as an argument.
Any other discussions about attempts to transform Java/C/C++/D grammar
(where '\n' is just a space) to FORTRAN/BASIC-derived line oriented
grammars
(Python/Ruby/Lua/etc) I'll left for off-list conversations.
Nobody's attempting to do anything of the sort - the ASI rules have been
unchanged for a long time.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Why is .bind so slow?
Sorry Jeff, but this is actually not the case. The performance consequences from using .bind() can be quite severe because it pollutes type information and disables fast paths. Not 'your entire application runs in the interpreter' slow, but surprisingly slow. It can even slow down code paths where .bind()/bound functions are not being used because of how inline caches and such tend to work in modern engines. The problem here isn't that 'calling a bound function is slow'; it's a more general problem that the introduction of bound functions into an existing application can make the application get slower in places where the bound functions aren't being used. I do agree with the general principle that it is not likely to be the biggest performance problem, but it's surprisingly harmful. On a related note, it would certainly be unwelcome if arrow functions had the same downsides. -kg On Sat, Jul 13, 2013 at 12:15 PM, Jeff Walden jwalden...@mit.edu wrote: On 07/12/2013 02:54 PM, Allen Wirfs-Brock wrote: 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? I'm pretty sure no implementation has seriously tried to optimize bound functions, and that that's the major reason for any slowness. I don't think there's anything fundamentally difficult about optimizing bound functions. It's just never been a priority for engines, because it doesn't show up in benchmarks and because the perf bugs for it are less pressing than other perf work is, as bound functions remain underused on the web. Chicken and egg? Sure. In the meantime, while I wouldn't currently question (as a purely pragmatic choice) avoiding bind in highly intensive code where every bit of perf matters, I do think bound functions are fast enough for the vast majority of cases. The overhead of calling a bound function will rarely be the difference between adequate and inadequate performance. Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Language Negotiation API
On Jul 13, 2013, at 12:37 , André Bargull andre.barg...@udo.edu wrote: On 7/13/2013 8:48 PM, Andy Earnshaw wrote: On Sat, Jul 13, 2013 at 1:05 PM, André Bargull andre.barg...@udo.edu mailto:andre.barg...@udo.edu wrote: Only exposing CanonicalizeLanguageTag does not seem useful to me without having access to IsStructurallyValidLanguageTag. Most likely a combined IsStructurallyValidLanguageTag + CanonicalizeLanguageTag function is necessary/wanted for most use cases. Hmm. I'm not sure I'd agree it's necessary. IsStructurallyValidLanguageTag makes sense as an abstract function because you need to throw accordingly when an invalid tag is passed to the constructors or methods. However, it's still the developer's responsibility to make sure their tags are valid during the development process. Canonicalisation would still throw an error if the tag is invalid. CanonicalizeLanguageTag isn't even defined for non-structurally valid language tags. That's why I meant a combined IsStructurallyValidLanguageTag + CanonicalizeLanguageTag function is more useful than access to the bare CanonicalizeLanguageTag function. Correct. As currently specified, the CanonicalizeLanguageTag abstract operation assumes that its input is a String value that's a structurally valid language tag. An API cannot make such assumptions - it has to be ready to deal with any input, as well as the absence of input. It has to do something like the steps in CanonicalizeLocaleList 8.c.ii-iv before calling the current CanonicalizeLanguageTag. Before we get too much into spec details: Do others believe that exposing API as proposed by Zbigniew would be useful? Norbert ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: more numeric constants please (especially EPSILON)
We should just add http://wiki.ecmascript.org/doku.php?id=strawman:bignums to ES7. /be Jeff Walden wrote: 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: Maps and Sets, goodbye polyfill ?!
you know what's funny? VBScript had static/fixed classes and immutable
objects in 1999 and goddammit nobody ever thought that was cool!
I've also proposed [static/fixed/frozen classes](
https://code.google.com/p/vbclass/) a while ago and also asked why
`Object.freeze({})` makes the object slower, instead of faster, to deal
with, as it would/could be a `prototype` and maybe marked as static ...
In another recent thread I was (wrongly) asking about CTypes meaning binary
data where developers can devine their own static shapes C struct like
and apparently this is still an ES6 thing.
Interesting time in this new JS era ... :-)
On Sat, Jul 13, 2013 at 2:02 AM, Brian Di Palma off...@gmail.com wrote:
OK. So we have reached Peak JavaScript then.
If people write JS code without triggering shape changes then the JIT
should be able to produce code that can match a JVM?
If there was something that I could do as a developer that could help
the JIT I would do it.
Would ES6 classes not make the creation of shapes a lot easier? From
what I understand it takes time to figure out shapes/hidden-classes.
Well I'm marking this object as a class, does that help?
It would be interesting if engines provided feedback on when we
developers break the optimistic optimizations.
On Sat, Jul 13, 2013 at 9:43 AM, David Bruant bruan...@gmail.com wrote:
Le 13/07/2013 10:21, Brian Di Palma a écrit :
I was just wondering
if the 'const' keyword would help give JS another small performance
boost.
Unlikely. Const can be almost statically inferred (no assignment to a
given
variable). The almost refers to cases where eval happens. Worst case,
if
there is no assignment, a variable can be optimistically optimized as
const.
If the value is changed via eval, then de-optimize (but in practice,
eval is
rare, so the optimistic optimization will be worth it)
As Andreas points out the major issue is that JS is highly dynamic,
this can be very useful sometimes but for most code it's not required.
Maybe if you mark everything as const or freeze/seal classes then
maybe JS engines will optimize for that code.
JS engines already optimistically optimize assuming code remains stable
(for
objects, V8 has hidden classes, SpiderMonkey has the equivalent shape
feature) and deoptimizes when the dynamic features are being used.
It might be one of the reason why maps are better at being maps than
objects
(since objects seem to have been optimized for cases where they are
stable)
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Why is .bind so slow?
this makes more sense than `callee` since `.bind()` functions are slow even
in `use strict` scenarios.
However, I was not aware about the fact arrow functions have no arguments
access at all ... between cool and limiting if you ask me but if
performances are better then it's OK.
Also OK would be to have a way to flag a function or a bound one static
so that no `arguments` or `caller` will ever be available 'cause if this is
the performance problem developers would love to have a better way to
improve there.
In the DOM world, as example, all bound functions accepts one single
argument, the event object, while in node.js world basically all emitted
functions accept 2 arguments and never/rarely more than two.
As somebody said already in another thread, me, as developer, would love to
help the JS engine to go faster where needed!
Regards
On Sat, Jul 13, 2013 at 12:39 PM, Mark S. Miller erig...@google.com wrote:
Arrow functions, whether strict or non-strict, are not supposed to have
their own |arguments|
On Sat, Jul 13, 2013 at 11:55 AM, Jeff Walden jwalden...@mit.edu wrote:
On 07/12/2013 04:59 PM, Andrea Giammarchi wrote:
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)
Sadly, based on the arrow-function patches I've reviewed in SpiderMonkey,
I don't believe this will be necessarily true. Arrow functions and
bind-bound functions are two rather different beasts. Bind-bound functions
are potentially constructible; arrow functions never are.
|arguments.callee| inside a function that's been bound doesn't refer to
the bound function -- it refers to the lexical entity. (That is, |function
f() { return arguments.callee; } f.bind(null)()| is |f|, not |b|.)
|arguments.callee| inside an arrow function -- at least, so long as arrow
functions aren't automatically strict, which decision I would revisit --
refers to the arrow function. I expect there are other differences I'm not
yet aware of, that would affect having a common implementation of the two
concepts.
It seems like a pretty bad idea to me for arrow functions to not be
substantially semantically similar to bind-bound functions, but they are as
it stands now. I wish I had the time to sit down and think through a solid
unification of the two concepts.
Jeff
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Why is .bind so slow?
not a part, I am imaging already a scenario where everyone will start
avoiding `.bind()` in order to use arrow functions because these are faster
... something like:
```javascript
obj.method = function () {
return (e) = {
// rest here
};
};
node.addEventListener('evt', obj.method());
```
... I don't really like the approach ... can anyone think about a way to
have arrowified functions at definition time? Will classes allow arrow
functions magic inline ? nothing to bind anymore in this case ... different
from the JS I know but that might work pretty well for performance ...
although the prototype would be even more messed up ...
On Sat, Jul 13, 2013 at 9:47 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
this makes more sense than `callee` since `.bind()` functions are slow
even in `use strict` scenarios.
However, I was not aware about the fact arrow functions have no arguments
access at all ... between cool and limiting if you ask me but if
performances are better then it's OK.
Also OK would be to have a way to flag a function or a bound one static
so that no `arguments` or `caller` will ever be available 'cause if this is
the performance problem developers would love to have a better way to
improve there.
In the DOM world, as example, all bound functions accepts one single
argument, the event object, while in node.js world basically all emitted
functions accept 2 arguments and never/rarely more than two.
As somebody said already in another thread, me, as developer, would love
to help the JS engine to go faster where needed!
Regards
On Sat, Jul 13, 2013 at 12:39 PM, Mark S. Miller erig...@google.comwrote:
Arrow functions, whether strict or non-strict, are not supposed to have
their own |arguments|
On Sat, Jul 13, 2013 at 11:55 AM, Jeff Walden jwalden...@mit.edu wrote:
On 07/12/2013 04:59 PM, Andrea Giammarchi wrote:
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)
Sadly, based on the arrow-function patches I've reviewed in
SpiderMonkey, I don't believe this will be necessarily true. Arrow
functions and bind-bound functions are two rather different beasts.
Bind-bound functions are potentially constructible; arrow functions never
are. |arguments.callee| inside a function that's been bound doesn't refer
to the bound function -- it refers to the lexical entity. (That is,
|function f() { return arguments.callee; } f.bind(null)()| is |f|, not
|b|.) |arguments.callee| inside an arrow function -- at least, so long as
arrow functions aren't automatically strict, which decision I would revisit
-- refers to the arrow function. I expect there are other differences I'm
not yet aware of, that would affect having a common implementation of the
two concepts.
It seems like a pretty bad idea to me for arrow functions to not be
substantially semantically similar to bind-bound functions, but they are as
it stands now. I wish I had the time to sit down and think through a solid
unification of the two concepts.
Jeff
___
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
