generic swap method in javascript
in [JavaScript]
|
Prev: FAQ Topic - How can I see in javascript if a web browser acceptscookies? (2010-06-16)
Next: FAQ Topic - How can I see in javascript if a web browser accepts cookies? (2010-06-16)
From: Lasse Reichstein Nielsen on 16 Jun 2010 12:50 VK <schools_ring(a)yahoo.com> writes: > Do you have links to documents proving Mozilla's exclusive rights to > JavaScript standardization or/and Mozilla's extensions > "standardization priority" ? I don't know if there is a reason that somebody else can't make a competing specification also called JavaScript (if they can get permission to use the trademark from Oracle, and if Mozilla doesn't already have some exclusive agreement), but so far, nobody have. That means that JavaScript is, so far, only used for the familiy of languages created first by Netscape and later continued by Mozilla. http://ejohn.org/blog/versions-of-javascript/ There are other ECMAScript implementations that call the language they implement JavaScript, but at best they are extensions of JavaScript 1. There are no non-Mozilla implementations of JavaScript 1.6 and above (well, maybe Tamarin, since it is the only non-Mozilla engine to support E4X). /L -- Lasse Reichstein Holst Nielsen 'Javascript frameworks is a disruptive technology'
From: VK on 16 Jun 2010 13:59 On Jun 16, 8:50 pm, Lasse Reichstein Nielsen <lrn.unr...(a)gmail.com> wrote: > I don't know if there is a reason that somebody else can't make a > competing specification also called JavaScript The reason was already given, see http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/dc32e329ae85d989 For the opposite there is so far no reason why I cannot make a BASIC version and call it ECMAScript(tm). I am really getting closer and closer to the decision of doing it for the US and the EU at least. The usage will be free for anywhere except mozilla.org and c.l.j. where I'll require a solid royalty fee for each use. > (if they can get > permission to use the trademark from Oracle, and if Mozilla doesn't > already have some exclusive agreement), but so far, nobody have. Being a wholly owned subsidiary doesn't mean patent and trademark transfer to the parent company unless spelled in the purchase documents. It is not the case for Sun, so JAVASCRIPT in any case or any case mixture remains Sun property as of now. > That means that JavaScript is, so far, only used for the family of > languages created first by Netscape and later continued by Mozilla. The issue was described in depth in the linked thread. If you insist on a purely genealogical lineage then the most authoritative JavaScript body then is AOL who bought Netscape, Inc. with all their stuff back in November 24, 1998 ;-)
From: Lasse Reichstein Nielsen on 16 Jun 2010 14:50 Richard Cornford <Richard(a)litotes.demon.co.uk> writes: > On Jun 16, 12:49 pm, Thomas 'PointedEars' Lahn wrote: >> I would also be positively surprised if the creation of an Array >> instance, a property lookup and two assignments was more efficient >> than a variable declaration and three assignments. > > So would I, but it should be cheaper than a function call (as that > implies the creation of a couple of objects) and if this could be done > with a function call (which it cannot) there aren't that many people > who would worry about implementing it as one. Function calls don't necessarily have to create any objects. Most function calls can be handled by just putting the arguments on the stack and using them from there. >> That said, I would like very much other implementations to adopt >> the desctructuring assignment and ES 6 "Harmony" to specify it. > > Which itself implies the creation of very temporary objects. The pattern [x,y] = [e1,e2]; should be detectable at compile time, so the introduction of the intermediate array can be optimized away. If the deconstructing assignment is introduced, it's likely to be used exactly for swapping variable values, and then I'll bet that optimization will be made. /L -- Lasse Reichstein Holst Nielsen 'Javascript frameworks is a disruptive technology'
From: Dmitry A. Soshnikov on 16 Jun 2010 15:17 On 16.06.2010 22:50, Lasse Reichstein Nielsen wrote: > Richard Cornford<Richard(a)litotes.demon.co.uk> writes: > >> On Jun 16, 12:49 pm, Thomas 'PointedEars' Lahn wrote: > >>> I would also be positively surprised if the creation of an Array >>> instance, a property lookup and two assignments was more efficient >>> than a variable declaration and three assignments. >> >> So would I, but it should be cheaper than a function call (as that >> implies the creation of a couple of objects) and if this could be done >> with a function call (which it cannot) there aren't that many people >> who would worry about implementing it as one. > > Function calls don't necessarily have to create any objects. > Most function calls can be handled by just putting the arguments on > the stack and using them from there. > Well, you have to choose which level to discuss -- the specification or implementation(s). The later is harder in respect that you should examine several/all implementations to statement this. Although, only one implementation is enough to assume. But by the specification, some "system" objects are created every time on entering the execution context with the "function" type of code (it can be activation object in ES3, or lexical/variable environment(s) and environment record(s) in ES5). >>> That said, I would like very much other implementations to adopt >>> the desctructuring assignment and ES 6 "Harmony" to specify it. >> >> Which itself implies the creation of very temporary objects. > > The pattern > [x,y] = [e1,e2]; > should be detectable at compile time, so the introduction of the > intermediate array can be optimized away. Moreover, it can be done syntactically without brackets, as in Python: x, y = e1, e2; > If the deconstructing assignment is introduced, it's likely to > be used exactly for swapping variable values, Swapping without "third" can be done with simple arithmetic operations: A = A - B B = A + B A = B - A > and then I'll bet > that optimization will be made. Yes, it's quite logical. Dmitry.
From: Lasse Reichstein Nielsen on 16 Jun 2010 16:41
"Dmitry A. Soshnikov" <dmitry.soshnikov(a)gmail.com> writes: > On 16.06.2010 22:50, Lasse Reichstein Nielsen wrote: >> Richard Cornford<Richard(a)litotes.demon.co.uk> writes: >> >>> So would I, but it should be cheaper than a function call (as that >>> implies the creation of a couple of objects) and if this could be done >>> with a function call (which it cannot) there aren't that many people >>> who would worry about implementing it as one. >> >> Function calls don't necessarily have to create any objects. >> Most function calls can be handled by just putting the arguments on >> the stack and using them from there. >> > Well, you have to choose which level to discuss -- the specification > or implementation(s). The later is harder in respect that you should > examine several/all implementations to statement this. Although, only > one implementation is enough to assume. Agreed. In this case, the statement was that "it should be cheaper". That means that we are talking implementation, not specification (the specification has no performance characteristics). > But by the specification, some "system" objects are created every time > on entering the execution context with the "function" type of code (it > can be activation object in ES3, or lexical/variable environment(s) > and environment record(s) in ES5). True. But many javascript functions don't actually need a physical representation of these "objects". Environments are purely specification tools, since they are never exposed, as objects, to user code. The arguments object is interesting because it can never be accessed from outside its scope. That means that you can determine (or approximate safely) whether it is ever used, and if it isn't, you also don't need to actually create an object for that. Example: function foo(a,b) { return a + b; } This function doesn't contain any closure constructions. It doesn't access any scoped variables. It doesn't use the arguments object. There is nothing preventing an implementation from just reading parameters off the stack, add them together, and return the result (on the stack or in a register). >> The pattern >> [x,y] = [e1,e2]; >> should be detectable at compile time, so the introduction of the >> intermediate array can be optimized away. > > Moreover, it can be done syntactically without brackets, as in Python: > > x, y = e1, e2; I'd prefer that. Or (x,y) = (e1,e2); // except it's ambiguous with the stupid comma operator. But then, I think any modern type system should have arbitrary tuples. Heck, I've seen languages with a swap primitive :) x :=: y; >> If the deconstructing assignment is introduced, it's likely to >> be used exactly for swapping variable values, > > Swapping without "third" can be done with simple arithmetic operations: > > A = A - B > B = A + B > A = B - A Try that for strings :) It's generally a bad idea to be "too smart" in a high-level language. If you do: int x,y; ... x^=y;y^=x;x^=y; to swap integers in, say, C++, then the compiler might not be able to do as good a job as if it could recognize that you were doing a swap. It might know low-level tricks for swapping that can't be expressed directly in the high-level language (like knowing that both values are in registers at the moment, so they can be swapped by a single xchg instruction (if on x86)). /L -- Lasse Reichstein Holst Nielsen 'Javascript frameworks is a disruptive technology' |