consider adding more [no LineTerminator here] to avoid problem caused by omit the semicolon
Hi, everyone,
During some recent discussion in Chinese JS community, I've noticed
several case which JS behave out of user's expect if omitting the
semicolon.
See the following code:
var a = this.a // here no semicolon will be auto inserted
[1,2,3].forEach(function(){
// do something
})
(function(){
//do something
})() // here no semicolon will be auto inserted
(function(){
//do something else
})()
I was thinking that if we could change some grammar rules to make it
behave as most user's expect. Just adding several [no LineTerminator
here] will do so:
CallExpression :
MemberExpression [no LineTerminator here] Arguments
CallExpression [no LineTerminator here] Arguments
CallExpression [no LineTerminator here] [ Expression ]
CallExpression . IdentifierName
Though some of you might consider omitting the semicolon as a bad
style, but its used by several group and company （including zepto.js
and npmjs）. I think this change will benefit them a lot with very
small side effect.
/Shaofei
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: [[strawman:data_parallelism]] |this| and fat arrows
Hey Mark,
You asked How/why might including index and the array itself distract the
programmer from parallel thinking?
If we present index as a location and not as the nth invocation of kernel
function then we are fine. Array.map overloads index to serve both purposes. My
concern is that if we are too close to Array then programmers will assume we
are the same and the same sequential semantics will hold. There is nothing
inherently non-parallel about a location.
You are correct that we are talking more about programmer psychology, art, and
pedagogy and there is no formal technical reason to go either way. While
passing 3 arguments might be more expensive than passing one in today's
implementations there are probably compiler optimizations that can ameliorate
the effects.
Let's look closely at the change you are suggesting on a very simple map
invocation.
function add1(element) {return element+1;}
strawmanPA.map(add1);
alternatePA.map(add1);
OK, JavaScript's argument passing semantics mean no difference for the common
case where the result is dependent upon just the element. The alternate is even
upwardly compatible.
Now let's consider a typical geometric decomposition function like a vector
blur.
function blurStrawman(index, array) {
if (index 1) return array[index];
return (array[index]+array[index-1])/2;
}
function blurAlternate(element, index, array) {
if (index 1) return element;
return (element+array[index-1])/2;
}
strawmanPA.combine(blurStrawman);
strawmanPA.map(blurAlternate);
OK, blurAlternate again seems reasonable.
I've played with other codes and I'm finding it increasingly hard to argue
against your suggestions for arrays. Future proofing the cases where we might
want to extend ParallelArray to objects seems fine since JavaScript blurs field
names and indices allowing for index to have a reasonable meaning in the
context of objects.
Unless someone else speaks up I'll drop combine and change map and filter so
the kernel function takes element, index, array.
Cheers,
- Rick
-Original Message-
From: Mark S. Miller [mailto:erig...@google.com]
Sent: Friday, June 15, 2012 6:06 PM
To: Hudson, Rick
Cc: es-discuss
Subject: Re: [[strawman:data_parallelism]] |this| and fat arrows
On Fri, Jun 15, 2012 at 11:35 PM, Hudson, Rick rick.hud...@intel.com wrote:
Hey Mark,
ParallelArray and index are left out because of our desire to provide a few
good methods that help/force programmers to think about parallel algorithms
and not just speeding up sequential algorithms. Array map is really just
syntactic sugar for for loops and invites thinking that depends on order. For
ParallelArray map we felt that the value was the semantically important thing
and the user should not be distracted by the index. Not having index
available is one step towards thinking in more parallel ways.
Hi Rick, the claim made in the paragraph above seems to be the core
argument. I respect the kind of argument you're making -- programmer
psychology is important, and it is our responsibility as language
designers to take it into account, and to help steer programmers
towards certain ways of thinking about the problem and away from
others. Sometimes these psychological issues have no corresponding
formal basis, but are still important nevertheless. Arguments by
non-psychologists like us about psychology can often be fuzzy, but
this does not relieve us of responsibility of taking these into
account.
However, I don't have any intuition that supports the specific claim.
Let's take map specifically. How/why might including index and the
array itself distract the programmer from parallel thinking? First, do
we agree that there's no formal problem, and the issue is only
psychology? If so, perhaps you could provide some examples that would
help illustrate the psychological issue you have in mind? At this
point, I just don't get it.
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: consider adding more [no LineTerminator here] to avoid problemcaused by omit the semicolon
var a = this.a // here no semicolon will be auto inserted
[1,2,3].forEach(function(){
// do something
})
Consider
arr.map(function(..){..}) // no semicolon wanted here
[..]
(function(){
//do something
})() // here no semicolon will be auto inserted
(function(){
//do something else
})()
Consider
curried_async_function(..first argument set..) // no semicolon wanted
here
(function(result){..}) // callback argument
Unfortunately, while ASI creates obvious problems, those do
not seem to have obvious solutions. Not to mention that any
actual changes to ASI might break existing code.
My own favourite approach would link ASI to layout/indentation,
and introduce warnings instead of breaking code:
1 if ASI kicks in, but indentation suggests statement continuation,
issue a warning
2 if ASI does not kick in, but indentation suggests new statement,
issue a warning
Item 2 would cover your examples, without breaking mine,
while item 1 would cover another popular ASI trap:
return // no semicolon intended here
{..}
while still allowing for
return// semicolon intended here
dead_code()
Claus
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Detecting the type of a DOM object
I'm going to try to move the discussion of this issue to es-discuss via a separate message as it is mostly about Proxy design. (bcc'ing public-script-coord) the start of this subthread is the following which identifies that historically the [[HasInstance]] extension point has been used (at least conceptually) to provide alternative instanceof semantics. On Jun 21, 2012, at 7:30 AM, Boris Zbarsky wrote: On 6/21/12 4:15 AM, David Bruant wrote: Le 21/06/2012 07:30, Boris Zbarsky a écrit : Alternately, we could try to make instanceof actually work cross-global? +1, but eternal web worry: won't it break the web? It works cross-global for DOM objects in Gecko right now. We're actually deliberately breaking that in the WebIDL bindings at the moment, so the actual web compat breakage for us is in the other direction: as we move to WebIDL with its stricter instanceof sites might break. On Jun 22, 2012, at 8:14 AM, Tom Van Cutsem wrote: 2012/6/22 David Bruant bruan...@gmail.com For the record, rationale for not including a trap for instanceof was described here: http://wiki.ecmascript.org/doku.php?id=harmony:proxies#interaction_with_instanceof We've gone through this in detail before. There even was a strawman, but it got deferred, see http://wiki.ecmascript.org/doku.php?id=strawman:proxy_instanceof From that strawman's feedback section: TC39 November 2010 meeting: after a meeting with the Web IDL editors, agreed that Web IDL should not expose the multiple inheritance. Hence, a custom [[HasInstance]] would not be necessary to wrap these host objects. But the usage from FireFox that was recently identified isn't particularly related to multiple inheritance. There may be other use cases for a custom [[HasInstance]] (outside of Web IDL), but until such cases are identified we agreed not to pursue this strawman in the interest of not further complicating the Proxy API. This needs to be part of what we cover on es-discuss, but my position is that [HasInstance]] is a clearly defined legacy object behavior extension point. If it isn't need it should go away entirely. If it has utility, then it should be part of the proxy handler surface area because that the mechanism for exposing such extension points into ES code. I don't think the new direct proxies API impacts this strawman, so technically I see no reason why proxies can't have a [[HasInstance]] trap if needed. I agree, I don't see that it presents any technical hurdles. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: consider adding more [no LineTerminator here] to avoid problem caused by omit the semicolon
On Fri, Jun 22, 2012 at 4:08 AM, 程劭非 csf...@gmail.com wrote: CallExpression : MemberExpression [no LineTerminator here] Arguments CallExpression [no LineTerminator here] Arguments I'm reminded of fab.js: https://github.com/jed/fab which this would break, but maybe that's a good thing. ;) -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Detecting the type of a DOM object
On 6/22/12 1:12 PM, Brandon Benvie wrote: While the issue identified may not be particularly related to multiple inheritance, the issue in general I think is a looming one in terms of the goal of being able to self-host the DOM in JS. It seems to be becoming more and more common for various kinds of partial interfaces/supplement/implements to be used in newer IDLs and many of those are difficult/impossible to fully represent in JavaScript without a lot of redundancy or backflips. Partial interfaces should be a non-issue. There is no supplement. implements is a bit of a pain, yes. Not just in JavaScript: see the recent thread on public-script-coord about the this-unwrapping behavior of implements -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Detecting the type of a DOM object
On Jun 22, 2012, at 10:12 AM, Brandon Benvie wrote: While the issue identified may not be particularly related to multiple inheritance, the issue in general I think is a looming one in terms of the goal of being able to self-host the DOM in JS. It seems to be becoming more and more common for various kinds of partial interfaces/supplement/implements to be used in newer IDLs and many of those are difficult/impossible to fully represent in JavaScript without a lot of redundancy or backflips. At the ES language level, the real question is whether the instanceof operator has a single semantics regardless of which objects it is applied to or whether it is an overloadable operator whose meaning is determined by its RHS operand. We should make a clear cut choice between those to alternatives. The legacy ES specification goes in the direction of the overloadable alternative. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Internationalization: NaN and Infinity in date formatting
#3 is also the alternative that seems right to me although since the Invalid Date behavior isn't in the standard and also isn't universal we could change the behavior of Date toLocaleString for ES6 and in the I18N API spec. to also throw. Invalid Date doesn't seems to me like a debugging message and not something that requires or is intended for end-user localization. Allen On Jun 21, 2012, at 10:33 PM, Brendan Eich wrote: Eric Albright wrote: I think detection of programming errors is important enough that I favor option 3. Next in line is option 1. Agreed. /be From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Norbert Lindenberg [ecmascr...@norbertlindenberg.com] Sent: Thursday, June 21, 2012 4:23 PM To: es-discuss Subject: Internationalization: NaN and Infinity in date formatting The ECMAScript Internationalization API Specification currently requires that Intl.DateTimeFormat.prototype.format(date) throws an exception if ToNumber(date) is not a finite Number (i.e., it's NaN or +/- Infinity). This is incompatible with the specification of Date.prototype.toLocale(|Date|Time)String, which unconditionally requires that a String value is returned. Most existing implementations of Date.prototype.toLocale(|Date|Time)String return Invalid Date for NaN (Infinity is mapped to NaN in the Date constructor). Safari tries to produce something in the format of a date string, with limited success: Mac OS 10.6.8: December -2147483629, 1969 -596:-31:-23 GMT-08:00 iOS 5.1.1 German: 1. Januar 1970 00:00:00 GMT-07:52:58 Internationalization libraries usually use integer-based representations of date and time and therefore don't deal with NaN and Infinity. I see the following options: 1) Change Intl.DateTimeFormat.prototype.format to return a localized form of Invalid Date for non-finite values. Pro: Most compatible with current implementations. Con: Internationalization libraries probably don't provide these localized strings, so the wrapper implementing the ECMAScript Internationalization API has to provide them. 2) Change Intl.DateTimeFormat.prototype.format to return Intl.NumberFormat.prototype.format(ToNumber(date)) for non-finite values. Pro: Relies on existing functionality. Con: Less descriptive and less compatible than 1. 3) Leave Intl.DateTimeFormat.prototype.format as is (i.e., throw an exception for non-finite values); specify Date.prototype.toLocale(|Date|Time)String to handle NaN directly before calling Intl.DateTimeFormat.prototype.format with other values. Pro: Easier detection of programming errors when using format(). Con: format() and toLocaleString() start to drift apart. I lean towards option 1). Comments? Thanks, Norbert ___ 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [[strawman:data_parallelism]] |this| and fat arrows
Hudson, Rick wrote: Unless someone else speaks up I'll drop combine and change map and filter so the kernel function takes element, index, array. +1 /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Detecting the type of a DOM object
Le 22/06/2012 18:13, Allen Wirfs-Brock a écrit : I'm going to try to move the discussion of this issue to es-discuss via a separate message as it is mostly about Proxy design. (bcc'ing public-script-coord) the start of this subthread is the following which identifies that historically the [[HasInstance]] extension point has been used (at least conceptually) to provide alternative instanceof semantics. I'd like to point out that whether the trap should be on the LHS or RHS of the instanceof expression is a non-trivial choice. If one is chosen over the other, I'd be interested to see this choice being justified. I don't think the new direct proxies API impacts this strawman, so technically I see no reason why proxies can't have a [[HasInstance]] trap if needed. I agree, I don't see that it presents any technical hurdles. There is a potential security issue. From the wiki [1] (in the case where the instance is a proxy trapping on instanceof): Security issue: the handler is given a reference to the function object (the right-hand side of the instanceof operator). This gives the handler the ability to generate new instances of that function. In my opinion, the issue stands if the choice is to have either the LHS or RHS of instanceof to trap on instanceof. The more general issue isn't about generating new instances, but about an object gaining access to another object it didn't have access to before the instanceof evaluation. Both cases result in a capability leak. To be more precise, currently, when you write a instanceof b, you don't expect either a or b to leak. This property should probably be preserved even with proxies. Here is a proposal that enable custom instanceof behavior and doesn't leak either a or b: Any object may (it's not compulsory) have an internal [[instanceofHint]] property (as usual, name isn't set in stone). Any function may have an internal [[instanceofMatch]] method. This method takes a value and returns a boolean. The value will be the [[instanceofHint]] property of an object [[HasInstance]](V) becomes: (Assume F is a Function object which has this [[HasInstance]] property) 1) If V is not an object, return false. 2) If V has an internal [[instanceofHint]] property and F has an internal [[instanceofMatch]] method, return F.[[instanceofMatch]](V.[[instanceofHint]]) 3) else goto step 2 of the ES5.1 [[HasInstance]] algorithm and continue from there. By default, objects do not have an [[instanceofHint]] or [[instanceofMatch]] property, so backward-compatibility is kept for ECMAScript 5 objects. Proxies can have a way to provide both an [[instanceofHint]] and [[instanceofMatch]] internal properties in their handlers to enable custom instanceof behavior. The trap for [[instanceofMatch]] is never handed objects, but only [[instanceofHint]], so as long as these do not leak instances, there cannot be a leak. For WebIDL objects, one way to use this is to say for instance: * Instances of interface A objects have 'A' as [[instanceofHint]] * The [[instanceofMatch]](v) method of constructors is roughly: return true if v refers to one of the constructor subclass and false otherwise. In that case, document instanceof Node would return true (regardless of which global Node or document came from), because document.[[instanceofHint]] would be 'HTMLDocument' and Node.[[instanceofMatch]] would recognize that as a subclass of Node. Instead of adding a new [[instanceofHint]] internal property, maybe the [[NativeBrand]] could be reused. David [1] http://wiki.ecmascript.org/doku.php?id=harmony:proxies#interaction_with_instanceof ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Detecting the type of a DOM object
Allen Wirfs-Brock wrote: I agree, I don't see that it presents any technical hurdles. Agreed. The DOM is alas built from nominal types, so many people believe (x instaceof I) for some WebIDL-declared interface I, even if that I came from another window or frame, should just work. Of course, if the other frame's I.prototype has been extended with a quux property, x won't inherit that property. But that's not how instanceof is used with DOM interfaces, at least. At this point I am in favor of making instanceof more useful for WebIDL consumers, than in being pedantic about prototype chains and multiple global objects. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Detecting the type of a DOM object
While the issue identified may not be particularly related to multiple inheritance, the issue in general I think is a looming one in terms of the goal of being able to self-host the DOM in JS. It seems to be becoming more and more common for various kinds of partial interfaces/supplement/implements to be used in newer IDLs and many of those are difficult/impossible to fully represent in JavaScript without a lot of redundancy or backflips. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Existential operator (was: ||= is much needed?)
On Thu, Jun 21, 2012 at 5:55 PM, Aymeric Vitte vitteayme...@gmail.comwrote: According to my previous posts I am quite convinced it has an interest, I remain perplex regarding the use of ?( , then, I am really curious to see CS's uses, could you please highlight some projects ? Certainly. Here's a brief sampling of some of the uses. Mostly cases where function values may not exist, or cases where you're passing a very heterogenous set of objects into an API, and you're not entirely sure what methods are available, but want to look for specific things. if typeof block is 'function' then block.call(@, params) else @[block]?(params) hashKeyFor: (obj) - obj?.hashKey?() or obj callback?(err, mappedRecords, env) unless varBase.hasProperties?() callback?() return true if lhs?.isEqual?(rhs) and rhs?.isEqual?(lhs) wrapper = wrapper?(core) or wrapper ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Internationalization: NaN and Infinity in date formatting
If throwing an exception from Date.prototype.toLocaleString is allowed, then I think that would be the best solution. I thought that would be considered an incompatible change since the spec doesn't mention it and no implementation (that I've tested with) does it. Norbert On Jun 22, 2012, at 9:25 , Allen Wirfs-Brock wrote: #3 is also the alternative that seems right to me although since the Invalid Date behavior isn't in the standard and also isn't universal we could change the behavior of Date toLocaleString for ES6 and in the I18N API spec. to also throw. Invalid Date doesn't seems to me like a debugging message and not something that requires or is intended for end-user localization. doesn't seems - seems? Allen On Jun 21, 2012, at 10:33 PM, Brendan Eich wrote: Eric Albright wrote: I think detection of programming errors is important enough that I favor option 3. Next in line is option 1. Agreed. /be From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Norbert Lindenberg [ecmascr...@norbertlindenberg.com] Sent: Thursday, June 21, 2012 4:23 PM To: es-discuss Subject: Internationalization: NaN and Infinity in date formatting The ECMAScript Internationalization API Specification currently requires that Intl.DateTimeFormat.prototype.format(date) throws an exception if ToNumber(date) is not a finite Number (i.e., it's NaN or +/- Infinity). This is incompatible with the specification of Date.prototype.toLocale(|Date|Time)String, which unconditionally requires that a String value is returned. Most existing implementations of Date.prototype.toLocale(|Date|Time)String return Invalid Date for NaN (Infinity is mapped to NaN in the Date constructor). Safari tries to produce something in the format of a date string, with limited success: Mac OS 10.6.8: December -2147483629, 1969 -596:-31:-23 GMT-08:00 iOS 5.1.1 German: 1. Januar 1970 00:00:00 GMT-07:52:58 Internationalization libraries usually use integer-based representations of date and time and therefore don't deal with NaN and Infinity. I see the following options: 1) Change Intl.DateTimeFormat.prototype.format to return a localized form of Invalid Date for non-finite values. Pro: Most compatible with current implementations. Con: Internationalization libraries probably don't provide these localized strings, so the wrapper implementing the ECMAScript Internationalization API has to provide them. 2) Change Intl.DateTimeFormat.prototype.format to return Intl.NumberFormat.prototype.format(ToNumber(date)) for non-finite values. Pro: Relies on existing functionality. Con: Less descriptive and less compatible than 1. 3) Leave Intl.DateTimeFormat.prototype.format as is (i.e., throw an exception for non-finite values); specify Date.prototype.toLocale(|Date|Time)String to handle NaN directly before calling Intl.DateTimeFormat.prototype.format with other values. Pro: Easier detection of programming errors when using format(). Con: format() and toLocaleString() start to drift apart. I lean towards option 1). Comments? Thanks, Norbert ___ 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 ___ 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: Internationalization: NaN and Infinity in date formatting
I prefer #3. The problem with #1 is that it's hard to detect--you always get a string back from the call and you have to inspect the string to find out that you don't want to display it to the user. Yuck. Even worse is that the string is localized and the caller can't be certain what that string will be on a given implementation. Double yuck. Addison -Original Message- From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] Sent: Friday, June 22, 2012 9:25 AM To: Brendan Eich Cc: es-discuss Subject: Re: Internationalization: NaN and Infinity in date formatting #3 is also the alternative that seems right to me although since the Invalid Date behavior isn't in the standard and also isn't universal we could change the behavior of Date toLocaleString for ES6 and in the I18N API spec. to also throw. Invalid Date doesn't seems to me like a debugging message and not something that requires or is intended for end-user localization. Allen On Jun 21, 2012, at 10:33 PM, Brendan Eich wrote: Eric Albright wrote: I think detection of programming errors is important enough that I favor option 3. Next in line is option 1. Agreed. /be From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Norbert Lindenberg [ecmascr...@norbertlindenberg.com] Sent: Thursday, June 21, 2012 4:23 PM To: es-discuss Subject: Internationalization: NaN and Infinity in date formatting The ECMAScript Internationalization API Specification currently requires that Intl.DateTimeFormat.prototype.format(date) throws an exception if ToNumber(date) is not a finite Number (i.e., it's NaN or +/- Infinity). This is incompatible with the specification of Date.prototype.toLocale(|Date|Time)String, which unconditionally requires that a String value is returned. Most existing implementations of Date.prototype.toLocale(|Date|Time)String return Invalid Date for NaN (Infinity is mapped to NaN in the Date constructor). Safari tries to produce something in the format of a date string, with limited success: Mac OS 10.6.8: December -2147483629, 1969 -596:-31:-23 GMT-08:00 iOS 5.1.1 German: 1. Januar 1970 00:00:00 GMT-07:52:58 Internationalization libraries usually use integer-based representations of date and time and therefore don't deal with NaN and Infinity. I see the following options: 1) Change Intl.DateTimeFormat.prototype.format to return a localized form of Invalid Date for non-finite values. Pro: Most compatible with current implementations. Con: Internationalization libraries probably don't provide these localized strings, so the wrapper implementing the ECMAScript Internationalization API has to provide them. 2) Change Intl.DateTimeFormat.prototype.format to return Intl.NumberFormat.prototype.format(ToNumber(date)) for non-finite values. Pro: Relies on existing functionality. Con: Less descriptive and less compatible than 1. 3) Leave Intl.DateTimeFormat.prototype.format as is (i.e., throw an exception for non-finite values); specify Date.prototype.toLocale(|Date|Time)String to handle NaN directly before calling Intl.DateTimeFormat.prototype.format with other values. Pro: Easier detection of programming errors when using format(). Con: format() and toLocaleString() start to drift apart. I lean towards option 1). Comments? Thanks, Norbert ___ 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: [[strawman:data_parallelism]] |this| and fat arrows
Hi Mark, Rick.
Apart from offering a cleaner mental model, which can be discussed at great
length, I believe there are practical advantages to having an index free model,
e.g., code reuse:
A minimal example: adding two vectors. Assume you already have a convenient
addition function on scalar elements like
function add (a,b) { return a+b;}
How do we go to vectors from here? The current map allows you to write
vecA.map(add, vecB);
Note here that all extra arguments to map are implicitly indexed in the same
way that the source array vecA is and both values are passed to the elemental
function. So the above applies add to all pairs of elements from vecA and vecB
(the usual JS semantics for [] applies to implicit selections also).
If we add index and array to the mix, we have to build an adapter for the
differing interfaces:
vecA.map((a, ignore, ignore2, b) = add(a, b), vecB)
Maybe just about bearable with fat arrows, plain horrible with function:
vecA.map( function(a, ignore, ignore2, b) { return add(a,b); }, vecB)
Stephan
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Hudson, Rick
Sent: Friday, June 22, 2012 5:14 AM
To: Mark S. Miller
Cc: es-discuss
Subject: RE: [[strawman:data_parallelism]] |this| and fat arrows
Hey Mark,
You asked How/why might including index and the array itself distract the
programmer from parallel thinking?
If we present index as a location and not as the nth invocation of kernel
function then we are fine. Array.map overloads index to serve both purposes.
My concern is that if we are too close to Array then programmers will assume
we are the same and the same sequential semantics will hold. There is
nothing inherently non-parallel about a location.
You are correct that we are talking more about programmer psychology, art,
and pedagogy and there is no formal technical reason to go either way. While
passing 3 arguments might be more expensive than passing one in today's
implementations there are probably compiler optimizations that can
ameliorate the effects.
Let's look closely at the change you are suggesting on a very simple map
invocation.
function add1(element) {return element+1;} strawmanPA.map(add1);
alternatePA.map(add1);
OK, JavaScript's argument passing semantics mean no difference for the
common case where the result is dependent upon just the element. The
alternate is even upwardly compatible.
Now let's consider a typical geometric decomposition function like a vector
blur.
function blurStrawman(index, array) {
if (index 1) return array[index];
return (array[index]+array[index-1])/2; } function blurAlternate(element,
index, array) {
if (index 1) return element;
return (element+array[index-1])/2;
}
strawmanPA.combine(blurStrawman);
strawmanPA.map(blurAlternate);
OK, blurAlternate again seems reasonable.
I've played with other codes and I'm finding it increasingly hard to argue
against your suggestions for arrays. Future proofing the cases where we might
want to extend ParallelArray to objects seems fine since JavaScript blurs field
names and indices allowing for index to have a reasonable meaning in the
context of objects.
Unless someone else speaks up I'll drop combine and change map and filter so
the kernel function takes element, index, array.
Cheers,
- Rick
-Original Message-
From: Mark S. Miller [mailto:erig...@google.com]
Sent: Friday, June 15, 2012 6:06 PM
To: Hudson, Rick
Cc: es-discuss
Subject: Re: [[strawman:data_parallelism]] |this| and fat arrows
On Fri, Jun 15, 2012 at 11:35 PM, Hudson, Rick rick.hud...@intel.com
wrote:
Hey Mark,
ParallelArray and index are left out because of our desire to provide a few
good methods that help/force programmers to think about parallel algorithms
and not just speeding up sequential algorithms. Array map is really just
syntactic sugar for for loops and invites thinking that depends on order. For
ParallelArray map we felt that the value was the semantically important thing
and the user should not be distracted by the index. Not having index available
is one step towards thinking in more parallel ways.
Hi Rick, the claim made in the paragraph above seems to be the core
argument. I respect the kind of argument you're making -- programmer
psychology is important, and it is our responsibility as language designers to
take it into account, and to help steer programmers towards certain ways of
thinking about the problem and away from others. Sometimes these
psychological issues have no corresponding formal basis, but are still
important nevertheless. Arguments by non-psychologists like us about
psychology can often be fuzzy, but this does not relieve us of responsibility
of
taking these into account.
However, I don't have any intuition that supports the specific claim.
Let's take map specifically. How/why might including index and the array
itself distract the programmer from parallel thinking? First, do we agree
Re: Internationalization: NaN and Infinity in date formatting
You're right, throwing is probably too much of a breaking change Norbert Lindenberg ecmascr...@norbertlindenberg.com wrote: If throwing an exception from Date.prototype.toLocaleString is allowed, then I think that would be the best solution. I thought that would be considered an incompatible change since the spec doesn't mention it and no implementation (that I've tested with) does it. Norbert On Jun 22, 2012, at 9:25 , Allen Wirfs-Brock wrote: #3 is also the alternative that seems right to me although since the Invalid Date behavior isn't in the standard and also isn't universal we could change the behavior of Date toLocaleString for ES6 and in the I18N API spec. to also throw. Invalid Date doesn't seems to me like a debugging message and not something that requires or is intended for end-user localization. doesn't seems - seems? Allen On Jun 21, 2012, at 10:33 PM, Brendan Eich wrote: Eric Albright wrote: I think detection of programming errors is important enough that I favor option 3. Next in line is option 1. Agreed. /be From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Norbert Lindenberg [ecmascr...@norbertlindenberg.com] Sent: Thursday, June 21, 2012 4:23 PM To: es-discuss Subject: Internationalization: NaN and Infinity in date formatting The ECMAScript Internationalization API Specification currently requires that Intl.DateTimeFormat.prototype.format(date) throws an exception if ToNumber(date) is not a finite Number (i.e., it's NaN or +/- Infinity). This is incompatible with the specification of Date.prototype.toLocale(|Date|Time)String, which unconditionally requires that a String value is returned. Most existing implementations of Date.prototype.toLocale(|Date|Time)String return Invalid Date for NaN (Infinity is mapped to NaN in the Date constructor). Safari tries to produce something in the format of a date string, with limited success: Mac OS 10.6.8: December -2147483629, 1969 -596:-31:-23 GMT-08:00 iOS 5.1.1 German: 1. Januar 1970 00:00:00 GMT-07:52:58 Internationalization libraries usually use integer-based representations of date and time and therefore don't deal with NaN and Infinity. I see the following options: 1) Change Intl.DateTimeFormat.prototype.format to return a localized form of Invalid Date for non-finite values. Pro: Most compatible with current implementations. Con: Internationalization libraries probably don't provide these localized strings, so the wrapper implementing the ECMAScript Internationalization API has to provide them. 2) Change Intl.DateTimeFormat.prototype.format to return Intl.NumberFormat.prototype.format(ToNumber(date)) for non-finite values. Pro: Relies on existing functionality. Con: Less descriptive and less compatible than 1. 3) Leave Intl.DateTimeFormat.prototype.format as is (i.e., throw an exception for non-finite values); specify Date.prototype.toLocale(|Date|Time)String to handle NaN directly before calling Intl.DateTimeFormat.prototype.format with other values. Pro: Easier detection of programming errors when using format(). Con: format() and toLocaleString() start to drift apart. I lean towards option 1). Comments? Thanks, Norbert ___ 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 ___ 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: consider adding more [no LineTerminator here] to avoid problem caused by omit the semicolon
I recently made a blog post concerning this issue [1], and my suggestion is
to prefix literals (function, array and friends) with `void`, as it's
almost (if not) designed for this case. So, (function(){}()); becomes void
function(){}(), [1,2,3].forEach(...) becomes void [1,2,3].forEach(...).
This is more resistant to typos as well, even in semicolon-preferring code.
Since Claus shared his work on the subject, I thought I'd also share a
little tool I made [2], called asifier. It's a sort of an education tool
that could be employed by editors, IDEs and such to show where semicolons
will be inserted. It can also replace a semicolonless file with inserted
semicolons so that missing semicolons isn't a problem for projects that
otherwise follow explicit semicolon rules.
Cheers,
Jussi
[1] http://blog.avd.io/posts/semicolonoscopy
[2] https://github.com/jussi-kalliokoski/asifier
On Fri, Jun 22, 2012 at 12:08 PM, 程劭非 csf...@gmail.com wrote:
Hi, everyone,
During some recent discussion in Chinese JS community, I've noticed
several case which JS behave out of user's expect if omitting the
semicolon.
See the following code:
var a = this.a // here no semicolon will be auto inserted
[1,2,3].forEach(function(){
// do something
})
(function(){
//do something
})() // here no semicolon will be auto inserted
(function(){
//do something else
})()
I was thinking that if we could change some grammar rules to make it
behave as most user's expect. Just adding several [no LineTerminator
here] will do so:
CallExpression :
MemberExpression [no LineTerminator here] Arguments
CallExpression [no LineTerminator here] Arguments
CallExpression [no LineTerminator here] [ Expression ]
CallExpression . IdentifierName
Though some of you might consider omitting the semicolon as a bad
style, but its used by several group and company （including zepto.js
and npmjs）. I think this change will benefit them a lot with very
small side effect.
/Shaofei
___
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: consider adding more [no LineTerminator here] to avoid problem caused by omit the semicolon
I recently started using void for IIFE's with no return value because it's
is by far the clearest way to indicate intent up front and helps to turn
the expression into something of a unique looking construct that helps
clearly identify it. It would be nice to see this practice become more
common because it seems to conveniently solve a number of problems at one.
On Fri, Jun 22, 2012 at 6:23 PM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
I recently made a blog post concerning this issue [1], and my suggestion
is to prefix literals (function, array and friends) with `void`, as it's
almost (if not) designed for this case. So, (function(){}()); becomes void
function(){}(), [1,2,3].forEach(...) becomes void [1,2,3].forEach(...).
This is more resistant to typos as well, even in semicolon-preferring code.
Since Claus shared his work on the subject, I thought I'd also share a
little tool I made [2], called asifier. It's a sort of an education tool
that could be employed by editors, IDEs and such to show where semicolons
will be inserted. It can also replace a semicolonless file with inserted
semicolons so that missing semicolons isn't a problem for projects that
otherwise follow explicit semicolon rules.
Cheers,
Jussi
[1] http://blog.avd.io/posts/semicolonoscopy
[2] https://github.com/jussi-kalliokoski/asifier
On Fri, Jun 22, 2012 at 12:08 PM, 程劭非 csf...@gmail.com wrote:
Hi, everyone,
During some recent discussion in Chinese JS community, I've noticed
several case which JS behave out of user's expect if omitting the
semicolon.
See the following code:
var a = this.a // here no semicolon will be auto inserted
[1,2,3].forEach(function(){
// do something
})
(function(){
//do something
})() // here no semicolon will be auto inserted
(function(){
//do something else
})()
I was thinking that if we could change some grammar rules to make it
behave as most user's expect. Just adding several [no LineTerminator
here] will do so:
CallExpression :
MemberExpression [no LineTerminator here] Arguments
CallExpression [no LineTerminator here] Arguments
CallExpression [no LineTerminator here] [ Expression ]
CallExpression . IdentifierName
Though some of you might consider omitting the semicolon as a bad
style, but its used by several group and company （including zepto.js
and npmjs）. I think this change will benefit them a lot with very
small side effect.
/Shaofei
___
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
