generic swap method in javascript
proxygeek
swap(a,b) function in Javascript.
Please point me to a discussion/link if it's already covered there.
Problem:
I need a method swap(a,b) which I can call with two variables as
params and it would swap the values of the two vars.
<snip>
....
....
function swap(a,b){ // This would NOT work as
intended
t = a;
a = b;
b = t;
}
....
....
var x = 10, y = 20;
swap(x,y);
alert("x = " + x + ", y = " + y); // should give x =
20, y = 10
....
</snip>
Above implementation would not work as here swap() does not know a
thing about x or y.
What would be the best solution for this?
Regards,
proxygeek
Thomas 'PointedEars' Lahn
> I could not find any worthwhile discussion on implementing a generic
> swap(a,b) function in Javascript.
Because there isn't one.
> Problem:
> I need a method swap(a,b) which I can call with two variables as
> params and it would swap the values of the two vars.
No, you don't.
> <snip>
> ....
> ....
> function swap(a,b){ // This would NOT work as
> intended
Original code should be posted so that it is readable and executable when
wrapped to the customary 72 to 80 characters per line. Always use multi-
line pre-comments, not single-line post-comments, for documentation
comments.
> t = a;
You "forgot" to declare `t', so it leaks to the outer scope.
> a = b;
> b = t;
> }
> ....
> ....
> var x = 10, y = 20;
> swap(x,y);
> alert("x = " + x + ", y = " + y); // should give x =
window.alert(…);
> 20, y = 10
See above
> ....
> </snip>
>
> Above implementation would not work as here swap() does not know a
> thing about x or y.
Congratulations, you have discovered call-by-value.
> What would be the best solution for this?
Do not use a function/method.
JavaScript 1.7+:
/* Destructuring assignment */
[y, x] = [x, y];
Other versions/implementations: as in swap()
See also <http://PointedEars.de/es-matrix>
PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300...@news.demon.co.uk> (2004)
VK
wrote:
> JavaScript 1.7+:
>
> /* Destructuring assignment */
> [y, x] = [x, y];
Not "JavaScript 1.7+" but Mozilla JavaScript 1.7+ thus Gecko platforms
thus 10%-20% of average visitors. IMO way below the level of an
acceptably universal solution.
> Other versions/implementations: as in swap()
? Do you imply that other platforms do implement call-by-reference for
primitives? It is not true.
To OP: to my surprise this question seems never was answered properly
in this newsgroup. The only relevant discussion I found was from
2000:
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/b72a4c3346057c66/e80dfd68d712c73c
and it doesn't contain any valuablу answer.
JavaScript as currently defined by ECMA-262 3rd ed. by design doesn't
allow primitives' swap in a separate function, because the function
gets such arguments by values, not by references.
If your code requires frequent primitive swaps, you may define an
intermediary var at the beginning so do not create it over and over
again and then:
var swap = null;
// ...
var x = 10, y = 20;
// ...
swap = x, x = y, y = swap;
window.alert("x = " + x + ", y = " + y);
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> JavaScript 1.7+:
>>
>> /* Destructuring assignment */
>> [y, x] = [x, y];
>
> Not "JavaScript 1.7+" but Mozilla JavaScript 1.7+
"Mozilla" is superfluous when talking about "JavaScript". I have explicitly
pointed out the other implementations, so there can not be ambiguity.
Unless, of course, one *wants* to misunderstand in order to have a case for
bickering and fairytales.
> thus Gecko platforms
JavaScript is not limited to "Gecko platforms".
> thus 10%-20% of average visitors.
That depends on the country to begin with.
> IMO way below the level of an acceptably universal solution.
Your opinion is worthless as you don't know what you are talking about.
>> Other versions/implementations: as in swap()
>
> ? Do you imply that other platforms do implement call-by-reference for
> primitives?
No.
> It is not true.
You are jumping to conclusions.
> To OP: to my surprise this question seems never was answered properly
> in this newsgroup. The only relevant discussion I found was from
> 2000:
OP: Do not listen to, and do not feed the troll.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
VK
wrote:
> "Mozilla" is superfluous when talking about "JavaScript".
Do you have links to documents proving Mozilla's exclusive rights to
JavaScript standardization or/and Mozilla's extensions
"standardization priority" ?
> > thus 10%-20% of average visitors.
> > IMO way below the level of an acceptably universal solution.
>
> Your opinion is worthless as you don't know what you are talking about.
I am talking about the destructuring assignment JavaScript extension
and its support across used browsers. What are you talking about
remains a mystery to the side readers.
> > ? Do you imply that other platforms do implement call-by-reference for
> > primitives?
>
> No.
That's good to know.
> OP: Do not listen to, and do not feed the troll.
You worthless trolling is annoying. Make your *working* version of
swap() for an ECMA-262 3rd ed. compliant platforms other than newest
Fx or just stop the tread pollution.
VK
> If your code requires frequent primitive swaps, you may define an
> intermediary var at the beginning so do not create it over and over
> again and then:
>
> var swap = null;
> // ...
> var x = 10, y = 20;
> // ...
> swap = x, x = y, y = swap;
> window.alert("x = " + x + ", y = " + y);
The other option is to not use stay-alone primitives but object
properties as objects being passed to functions by reference values:
var foo = {'a' : 10};
var bar = {'a' : 20};
swap(foo, bar, 'a');
window.alert(foo.a + ' ' + bar.a);
function swap(obj1, obj2, prop) {
var tmp = obj1[prop];
obj1[prop] = obj2[prop];
obj2[prop] = tmp;
}
Whichever is more (dis)convenient depends on your actual project.
Asen Bozhilov
> var foo = {'a' : 10};
> var bar = {'a' : 20};
>
> swap(foo, bar, 'a');
>
> window.alert(foo.a + ' ' + bar.a);
>
> function swap(obj1, obj2, prop) {
> var tmp = obj1[prop];
> obj1[prop] = obj2[prop];
> obj2[prop] = tmp;
>
> }
The whole point of thread is useless and as Thomas pointed out, he
does not need function/method especially "generic". He can use
standard approach, for example:
var foo = 10,
bar = 20;
foo = [bar, bar = foo][0];
Thomas 'PointedEars' Lahn
> VK wrote:
>> If your code requires frequent primitive swaps, you may define an
>> intermediary var at the beginning so do not create it over and over
>> again and then:
>>
>> var swap = null;
>> // ...
>> var x = 10, y = 20;
>> // ...
>> swap = x, x = y, y = swap;
>> window.alert("x = " + x + ", y = " + y);
>
> The other option is to not use stay-alone primitives but object
> properties as objects being passed to functions by reference values:
Which is neither generic nor the best way to do it. Thanks for playing.
--
PointedEars
VK
> The whole point of thread is useless and as Thomas pointed out, he
> does not need function/method especially "generic". He can use
> standard approach, for example:
>
> var foo = 10,
> bar = 20;
>
> foo = [bar, bar = foo][0];
Let's not reproduce the infamous "The Fox and the Grapes"
situation ;-)
http://en.wikipedia.org/wiki/The_Fox_and_the_Grapes
so like if something cannot be done in that way then it doesn't need
to be done in that way. There is nothing particularly strange in the
necessity to swap some values. If it needs to be done more than once
in the same program then there is nothing strange in the desire to
make it as a subroutine. The fact that it is not possible for stay
alone primitives in JavaScript is far of being obvious for people
coming from some other programming platforms. Yes, the task can be
still accomplished in a number of ways like yours or mine. No, it
cannot be accomplished in a subroutine for stay alone primitives.
Thomas 'PointedEars' Lahn
> The whole point of thread is useless and as Thomas pointed out, he
> does not need function/method especially "generic". He can use
> standard approach, for example:
>
> var foo = 10,
> bar = 20;
>
> foo = [bar, bar = foo][0];
That is generic, but the non-obvious code style aside, I would not want to
rely on that it works. The Specifications imply that the /ElementList/ is
evaluated from left to right [11.1.4], but does it follow that all
implementations must do that?
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. That said, I would like very much other
implementations to adopt the desctructuring assignment and ES 6 "Harmony" to
specify it.
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
Richard Cornford
> Asen Bozhilov wrote:
<snip>
>> foo = [bar, bar = foo][0];
>
> That is generic, but the non-obvious code style aside, I would not
> want to rely on that it works. The Specifications imply that the
> /ElementList/ is evaluated from left to right [11.1.4], but does
> it follow that all implementations must do that?
The specification doesn't imply that the evaluation order is left to
right, it mandates it, or at least that implementations behave as if
they do evaluate the element list from left to right, and that order
does matter. So it does follow that implementations must do that.
> 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.
> 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.
Richard.
John G Harris
wrote:
<snip>
>Problem:
>I need a method swap(a,b) which I can call with two variables as
>params and it would swap the values of the two vars.
<snip>
A way that works in javascript is to switch to a C++ mind-set and tell
yourself it's got to be an 'inline' function so it goes faster.
Now you copy-and-paste
var t = a; a = b; b = t;
from a handy text file and change a,b to x,y or whatever is needed at
that point in the code. Maybe your source-code editor will make this
easier.
John
--
John Harris
Thomas 'PointedEars' Lahn
> proxygeek wrote:
>> Problem:
>> I need a method swap(a,b) which I can call with two variables as
>> params and it would swap the values of the two vars.
>
> A way that works in javascript is to switch to a C++ mind-set and tell
> yourself it's got to be an 'inline' function so it goes faster.
*g*
> Now you copy-and-paste
> var t = a; a = b; b = t;
> from a handy text file and change a,b to x,y or whatever is needed at
> that point in the code. Maybe your source-code editor will make this
> easier.
Good idea. In fact, in Eclipse JSDT you can define this code template:
var ${temp} = ${a};
${a} = ${b};
${b} = ${temp};${cursor}
(Insert with Ctrl+Space, navigate with Tab.)
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Asen Bozhilov wrote:
>>> foo = [bar, bar = foo][0];
>>
>> That is generic, but the non-obvious code style aside, I would not
>> want to rely on that it works. The Specifications imply that the
>> /ElementList/ is evaluated from left to right [11.1.4], but does
>> it follow that all implementations must do that?
>
> The specification doesn't imply that the evaluation order is left to
> right, it mandates it, or at least that implementations behave as if
> they do evaluate the element list from left to right, and that order
> does matter. So it does follow that implementations must do that.
*Conforming* implementations. Tests pending…
>> 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)
No doubt about that.
> 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.
You've lost me here.
>> 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.
Yes. Your point being?
Lasse Reichstein Nielsen
> Not "JavaScript 1.7+" but Mozilla JavaScript 1.7+ thus Gecko platforms
> thus 10%-20% of average visitors.
JavaScript is the name for the Mozilla (nee Netscape) specified family
of languages. Adding "Mozilla" doesn't change anything (and it's not
part of the name of the language, that's just "JavaScript 1.7").
> IMO way below the level of an acceptably universal solution.
What is the reasonable limit for a universal solution? 100% seems
required.
(Not that I disagree with the conclusion).
> To OP: to my surprise this question seems never was answered properly
> in this newsgroup. The only relevant discussion I found was from
> 2000:
> http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/b72a4c3346057c66/e80dfd68d712c73c
> and it doesn't contain any valuablу answer.
>
> JavaScript as currently defined by ECMA-262 3rd ed. by design doesn't
> allow primitives' swap in a separate function, because the function
> gets such arguments by values, not by references.
Incorrect use of the "JavaScript" name. ECMA-262 doesn't specifiy
JavaScript (Mozilla does that).
> If your code requires frequent primitive swaps, you may define an
> intermediary var at the beginning so do not create it over and over
> again and then:
>
> var swap = null;
> // ...
> var x = 10, y = 20;
> // ...
> swap = x, x = y, y = swap;
Ick. What's wrong with semicolons now?
> window.alert("x = " + x + ", y = " + y);
/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'
Lasse Reichstein Nielsen
> 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).
VK
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 ;-)
Lasse Reichstein Nielsen
> 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.
Dmitry A. Soshnikov
> Richard Cornford<Ric...@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.
Lasse Reichstein Nielsen
> On 16.06.2010 22:50, Lasse Reichstein Nielsen wrote:
>> Richard Cornford<Ric...@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)).
Thomas 'PointedEars' Lahn
> "Dmitry A. Soshnikov" writes:
>> Lasse Reichstein Nielsen wrote:
>>> 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:
No, it can't. Check your assumptions.
>> x, y = e1, e2;
>
> I'd prefer that.
The two of you are missing the ambiguity here which prevents that from
working as intended in JavaScript already. That is _not_ a destructuring
assignment in ECMAScript implementations: it is evaluating x, assigning e1
to y, and evaluating e2. Changing the semantics here would break a lot of
existing scripts, and is therefore not going to happen.
> Or
> (x,y) = (e1,e2); // except it's ambiguous with the stupid comma
> operator.
That is why it should not be specified or implemented so; the LHS must
evaluate to y, and the RHS must evaluate to e2. The Mozilla people
(Brendan Eich?) picked the sensible way to provide this feature already.
> But then, I think any modern type system should have arbitrary tuples.
But thanks to the comma operator, that syntax would not be backwards
compatible in ECMAScript implementations. It is highly doubtful that it
would be implemented so. So we will probably have to live with Array
initializers als tuple replacement.
> Heck, I've seen languages with a swap primitive :)
> x :=: y;
I cannot say I like that a lot either. I also do not think it is a pattern
useful often enough for it to deserve any special syntax; I have not used it
in production code for a decade or so, thanks to efficient built-in sort
implementations. The use of the destructuring assignment here is more of a
happy coincidence; the feature was designed for extracting elements from
Arrays instead.
Evertjan.
> Swapping without "third" can be done with simple arithmetic operations:
>
> A = A - B
> B = A + B
> A = B - A
>
Many many years ago,
on a microprocessor called 2650,
there was an assembler opcode called:
swab
.. some programmers over here thought
this was the native spelling of swap.
However it ment "swap registers a and b"
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
rf
"Evertjan." <exjxw.ha...@interxnl.net> wrote in message
news:Xns9D9A77AD...@194.109.133.242...
> Dmitry A. Soshnikov wrote on 16 jun 2010 in comp.lang.javascript:
>
>> Swapping without "third" can be done with simple arithmetic operations:
>>
>> A = A - B
>> B = A + B
>> A = B - A
>>
>
> Many many years ago,
> on a microprocessor called 2650,
Hey, I had one of those. On a development board so one could solder stuff
like expansion ports and an extra K of memory onto it.
Great fun :-)
Can't remember much of the assembly language though after 35 years, except
that it was a bloody whole lot different to the IBM System 360 Assembler I
was then currently being employed to churn out line by tedious line.
Evertjan.
>
> "Evertjan." <exjxw.ha...@interxnl.net> wrote in message
> news:Xns9D9A77AD...@194.109.133.242...
>> Dmitry A. Soshnikov wrote on 16 jun 2010 in comp.lang.javascript:
>> Many many years ago,
>> on a microprocessor called 2650,
>
> Hey, I had one of those. On a development board so one could solder
> stuff like expansion ports and an extra K of memory onto it.
>
> Great fun :-)
>
> Can't remember much of the assembly language though after 35 years,
I bought 64 kiloBytes of memory from the States by post-order for 1000
guilders, then about $ 400 ?, while mainframe IBM memory was about $
100.000 for the same amount.
We could marvel doing a register exor "XOR0" with itself, sparing an extra
processor cycle from setting 000000 in the same register, speed mattered in
that era.
> except that it was a bloody whole lot different to the IBM System 360
> Assembler I was then currently being employed to churn out line by
> tedious line.
Philips had programmed a 2650 cross-assembler on the 360 btw.
Dmitry A. Soshnikov
> Dmitry A. Soshnikov wrote on 16 jun 2010 in comp.lang.javascript:
>
>> Swapping without "third" can be done with simple arithmetic operations:
>>
>> A = A - B
>> B = A + B
>> A = B - A
>>
>
> Many many years ago,
> on a microprocessor called 2650,
> there was an assembler opcode called:
>
> swab
>
> .. some programmers over here thought
> this was the native spelling of swap.
>
> However it ment "swap registers a and b"
>
Oh, didn't know; historically interesting, thanks.
Dmitry.
Richard Cornford
> Richard Cornford 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.
It is possible for - foo = [bar, bar = foo][0]; - to be optimised by a
complier such that no array object is ever created. The thing that
makes such an optimisation unlikely is that the construct is not that
common and javascript compliers need to be able to work quickly at
delivering an executable and so don't have much time to spend looking
at uncommon constructs to see if they could be optimised.
>>> 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.
Can be, but still the behaviour is specified in terms of objects being
created.
> 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.
Probably. This reminds me of the pre-ES5 discussions on -
Object.defineProperty - where it was suggested that the property
defining process could be heavily optimised to get rid of all of the
implied object creation. That is fine if you are using object literals
as the 'attributes' argument, but it seems likely that it will be
common to want to define numerous properties with identical property
descriptors. In that case it would seem like a good idea to create a
single object and pass it to multiple call to - Object.defineProperty
-, while it may actually be more efficient to write (copy-paste)
identical object literals for the 'attributes' argument for each call,
if an optimisation exists to treat that construct as syntax rather
than just a method call.
Richard.
VK
> We could marvel doing a register exor "XOR0" with itself, sparing an extra
> processor cycle from setting 000000 in the same register, speed mattered in
> that era.
EX (SP),HL ;;EX - from EXchange obviously
;;ZX Spectrum, Zilog Z80
;;my sweet youthhood :-)
VK
swap method in JavaScript:
http://groups.google.com/group/comp.lang.javascript/msg/d4920b7b20b920a7
The language and DOM interface specifics imply three distinct
situations for swapping values and it currently eliminates the
possibility of having a separate polymorphic method (function)
covering all of three together. Such situations are:
1. Swap stay-alone primitive values, thus primitive values which are
not property of any JavaScript object other than Global itself.
2. Swap property values of two JavaScript objects.
3. Swap elements of HTMLCollection (DOM0) or NodeList (DOM1 and
higher). Such collections normally do not allow direct assignments to
their members so specific DOM methods usage will be needed.
1.Swap stay-alone primitive values, thus primitive values
which are not property of any JavaScript object other
than Global itself
JavaScript functions receive primitives by value and there is no
keyword/flag to alter it to by reference pass. Respectively there is
no possibility in JavaScript to make a separate subroutine for stay-
alone primitives swap. The only option remains to use an inline set of
statements for each case. If swapping needs to be done more than once
in the same script it may be suggested to pre-declare the intermediary
variable and use a uniform set of statements, possibly pretty-printed
in a block of statements to make it visually as "functional" as
possible, for instance:
var iswap = null;
// DO other stuff
var v1 = 10;
var v2 = 15;
// swap block:
{
iswap =
v1, v1 = v2, v2 =
iswap
}
Note 1: By using the fact of Global properties reflection in window
host object it is possible to move the code in a separate subroutine
and to pass arguments as identifier literals:
var v1 = 10;
var v2 = 15;
swap('v1', 'v2');
function swap(a, b) {
var tmp = self[a];
self[a] = self[b];
self[b] = tmp;
}
This approach doesn't seep too convenient or flexible but still should
be mentioned for situations where window host object is presented.
Note 2: By using the destructuring assignment introduced in JavaScript
1.7 and currently supported on newest Gecko platforms it is possible
to use a shorter syntax like
var v1 = 10;
var v2 = 15;
[v1, v2] = [v2, v1];
See also: https://developer.mozilla.org/en/new_in_javascript_1.7
The use of destructuring assignments eliminates the necessity of an
intermediary variable but possibly introduces additional objects
creation: therefore the possible productivity gain remains disputable,
see this thread for details and arguments.
Note 3: If the swapping values are non-negative integers lesser or
equal to OxFFFFFFFF (dec 4294967295) then it is possible to avoid an
intermediary variable by using the XOR swap algorithm:
http://en.wikipedia.org/wiki/XOR_swap
Such approach is much lesser universal and it may break the internal
optimization mechanics, see wiki article and Lasse Reichstein Nielsen
in this thread:
http://groups.google.com/group/comp.lang.javascript/msg/af6f0ec2d576d8c6
End of stay-alone primitives situation. To be continued with two other
situations. Corrections are welcome.
Dmitry A. Soshnikov
> "Dmitry A. Soshnikov"<dmitry.s...@gmail.com> writes:
<snip>
>
> 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).
>
Yeah, logically, yes; I mentioned it the article of closures -- it can
be a general approach in any language -- if a functions do not have free
variables (with possibly analazing the whole chain), then it easily can
put arguments onto stack (or even, yes, registers), rather than use heap
for that, as generally is in languages which supports closures.
>
>>> 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.
>
Damn, really, ambiguity. This could be a good question for "quiz" also
(after everybody have learned that comma returns evaluation of its last
operand):
var a = 10, b = 20;
// everybody knows, that
// comma operator returns the
// evaluation of the last operand
20, 10; // 10
a, b // 20, the same, the last
a, b = b, a;
// or even so:
a, b = 20, 10;
console.log(a, b); // 10, 10 ? Nope, still 10, 20 of course ;)
Yes, this syntax (because of backward compats) isn't acceptable for ES;
in contrast with Python.
> But then, I think any modern type system should have arbitrary tuples.
>
> Heck, I've seen languages with a swap primitive :)
> x :=: y;
>
Interesting. Yes, why not? A good syntactic sugar, increasing the
abstraction, (even if it will cause some performance penalty) is good.
>>> 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 :)
>
Yeah, I know sure. Just mentioned thinking about numbers at that time
(with numbers also can be overflow, by the way).
> 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,
I've checked for the interest in the MS Visual Studio, in C++ -- nope,
it either do not know such optimization at all (even if I try to declare
vars as "register", although, the compiler can ignore it) and make full
operations -- as I see in disassembly window. Or make full optimization
removing my simple code with that operations :P Maybe it can be caught
in more complex examples and it will use that "xchg", don't know. For
the interested it possible to disassemble std:swap to see what's going
on in assembler representation. Although, that's just the particular
implementation.
> so they can be swapped
> by a single xchg instruction (if on x86)).
Yeah, I remember this command, although, I don't use the assembly
language on practice.
Dmitry.
Dmitry A. Soshnikov
> Lasse Reichstein Nielsen wrote:
>
>> "Dmitry A. Soshnikov" writes:
>>> Lasse Reichstein Nielsen wrote:
>>>> 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:
>
> No, it can't. Check your assumptions.
>
Did I say that I assume something? I confirmed. And that assertion was
related to Python. Though, I guess the word "can" made ambiguity. I mean
it "could" be as in Python. But, yeah, because of current implementation
of the comma operator, it (because of backward compats) -- can't.
>>> x, y = e1, e2;
>>
>> I'd prefer that.
>
> The two of you are missing the ambiguity here which prevents that from
> working as intended in JavaScript already. That is _not_ a destructuring
> assignment in ECMAScript implementations: it is evaluating x, assigning e1
> to y, and evaluating e2. Changing the semantics here would break a lot of
> existing scripts, and is therefore not going to happen.
>
>> Or
>> (x,y) = (e1,e2); // except it's ambiguous with the stupid comma
>> operator.
>
> That is why it should not be specified or implemented so; the LHS must
> evaluate to y, and the RHS must evaluate to e2. The Mozilla people
> (Brendan Eich?) picked the sensible way to provide this feature already.
>
>> But then, I think any modern type system should have arbitrary tuples.
>
> But thanks to the comma operator, that syntax would not be backwards
> compatible in ECMAScript implementations. It is highly doubtful that it
> would be implemented so. So we will probably have to live with Array
> initializers als tuple replacement.
>
Yep.
> the feature was designed for extracting elements from
> Arrays instead.
Possibly, it's from what is called pattern-matching in more older
languages (such as e.g. Erlang). There, if you want to extract elements
from "something" where "something", one can use that pattern matching:
[A, B] = [1, 2]
A and B will have 1 and 2 respectively. The same:
{Data, {OtherData, AndOther}} = {10, {"test", [1, 2, 3]}} to bind three
variables.
Dmitry.
Dmitry A. Soshnikov
<snip>
> There, if you want to extract elements
> from "something" where "something",
err, where "something" is _any_ term, but not only array (list). This is
a common ideology, thought, in other languages is presented partly, e.g.
only for arrays. Although, JS 1.7 supports this feature not only for
arrays, but for objects also.
Dmitry.
VK
2. Swap property values of two JavaScript objects
JavaScript objects are passed to function by reference value (the
"reference value" term is used to disambiguate C-like *reference which
doesn't exist in JavaScript). That allows to make a separate swap
subroutine as long as the property name can be passed as a literal,
for instance:
var jso1 = {'prop1' : 10};
var jso2 = {'prop1' : 15};
swap(jso1, jso2, 'prop1');
function swap(jsobj1, jsobj2, prop) {
var tmp = jsobj1[prop];
jsobj1[prop] = jsobj2[prop];
jsobj2[prop] = tmp;
}
End of property values of two JavaScript objects situation. To be
continued with the last situation. Corrections are welcome.
Benjamin 'BeRo' Rosseaux
> In article<Xns9D9A77AD...@194.109.133.242>,
> "Evertjan."<exjxw.ha...@interxnl.net> wrote:
>
>> Dmitry A. Soshnikov wrote on 16 jun 2010 in comp.lang.javascript:
>>
>>> Swapping without "third" can be done with simple arithmetic operations:
>>>
>>> A = A - B
>>> B = A + B
>>> A = B - A
>>>
>>
>> Many many years ago,
>> on a microprocessor called 2650,
>> there was an assembler opcode called:
>>
>> swab
>>
>> .. some programmers over here thought
>> this was the native spelling of swap.
>>
>> However it ment "swap registers a and b"
>
>
> swab R3 or swab (SP)
>
> for example to swap the bytes in register 3 or the top item on the stack.
>
Even on x86/x64 does exist a swap opcode instruction called xchg as
shorthand for "exchange", for example
xchg eax,ebx
which swaps the content between the registers eax and ebx.
Richard Cornford
> On 17.06.2010 0:41, Lasse Reichstein Nielsen wrote:
>>> Swapping without "third" can be done with simple arithmetic
>>> operations:
>
>>> A = A - B
>>> B = A + B
>>> A = B - A
>
>> Try that for strings :)
>
> Yeah, I know sure. Just mentioned thinking about numbers at that
> time (with numbers also can be overflow, by the way).
With javascript's double precision floating point numbers overflows
are possible, but loss of precision seems (much) more likely. Consider
what will happen if A is a number at the upper range of possible
number representations, say 1.0e308 and B is a number close to the
smallest (positive) number, say 5.0e-324. But the numbers don't have
to be as extreme as those:-
var A = 1.0e9;
var B = 1.0e-9;
A = A - B
B = A + B
A = B - A
// A is now zero
// B is now 1000000000
I have a vague recollection of once being shown a 'swapping' algorithm
for signed integers (with no third variable) that used only bitwise
operations to swap the values, avoiding any risk of overflows.
Obviously in javascript that would only be viable for 32 bit integers,
and adding two of those will not overflow the range of integers that
can be represented by an IEEE double precision floating point number.
Richard.
VK
http://groups.google.com/group/comp.lang.javascript/msg/a5f99302e2a1c5a5
http://groups.google.com/group/comp.lang.javascript/msg/c90c13f264ada061
)
3. Swap elements of HTMLCollection (DOM0) or NodeList (DOM1 and
higher)
Such collections normally do not allow direct assignments to their
members so specific DOM methods usage will be needed. IE DOM model
provides a proprietary swapNode method:
http://msdn.microsoft.com/en-us/library/ms536774%28VS.85%29.aspx
The W3C DOM model is still missing such method so different voodoo
dances with removeChild/appendChild/etc. are so far needed.
As the native swap method times more effective than any voodoo, first
it should be tried to use it if presented. If not, then the most
simple/effective replacement for init.W3Swap is highly welcome in this
thread.
<!DOCTYPE html>
<html>
<head>
<title>Test</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript">
var swapNodes = null;
function test() {
var pcol = document.getElementsByTagName('P');
swapNodes(pcol, 1, 2);
}
function init() {
swapNodes = (/*@cc_on true || @*/ false) ? init.IESwap : initW3Swap;
test();
}
init.IESwap = function(collection, index1, index2) {
var parentElement = collection.item(0).parentElement;
parentElement.children(index1).
swapNode(
parentElement.children(index2)
);
}
init.W3Swap = function(parentElement, index1, index2) {
// your code goes here
}
</script>
</head>
<body onload="init()">
<p>P1</p>
<p>P2</p>
<p>P3</p>
</body>
</html>
.
Thomas 'PointedEars' Lahn
> On 17.06.2010 4:53, Thomas 'PointedEars' Lahn wrote:
>> Lasse Reichstein Nielsen wrote:
>>> "Dmitry A. Soshnikov" writes:
>>>> Lasse Reichstein Nielsen wrote:
>>>>> 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:
>> No, it can't. Check your assumptions.
>
> Did I say that I assume something?
It sure looked so: "... can be done ..., [the same] as in Python".
> I confirmed.
OK, that was easy to misunderstand.
>> the feature was designed for extracting elements from Arrays instead.
>
> Possibly, it's from what is called pattern-matching in more older
> languages (such as e.g. Erlang). There, if you want to extract elements
> from "something" where "something", one can use that pattern matching:
>
> [A, B] = [1, 2]
>
> A and B will have 1 and 2 respectively. The same:
>
> {Data, {OtherData, AndOther}} = {10, {"test", [1, 2, 3]}} to bind three
> variables.
Thanks for the example. It led me to find out that
var [data, [otherData, another]] = [10, ["test", [1, 2, 3]]];
works in JavaScript 1.8.2 (and probably all 1.7+), too (that is,
data === 10
otherData === "test"
another === [1, 2, 3]
afterwards.)
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Dmitry A. Soshnikov
<snip>
>
> var [data, [otherData, another]] = [10, ["test", [1, 2, 3]]];
>
> works in JavaScript 1.8.2 (and probably all 1.7+), too (that is,
>
> data === 10
> otherData === "test"
> another === [1, 2, 3]
>
Yeah, moreover, pattern matching for objects also works since 1.7 as I see:
let {a: n} = {a: 10};
Thus, `n' becomes 10. It can be useful for shorthands in enumeration of
objects:
for (let {longPropertyName: name, otherProperty: other} in object) {
print(name, other);
}
Dmitry.
Dmitry A. Soshnikov
Yeah, and XOR algorithm won't help also in this case:
A ^= B;
B ^= A;
A ^= B;
// the same
// A is now zero
// B is now 1000000000
Dmitry.
Dmitry A. Soshnikov
<snip>
> for (let {longPropertyName: name, otherProperty: other} in object) {
> print(name, other);
> }
Err (forgot the correct syntax). Should be "for each" and this approach
is better use to iterate an array of objects:
var array = [
{a: 10, b: 20},
{a: 30, b: 40, c: 50}
];
for each (let {a: x, b: y} in array) {
print(x, y);
}
Result:
10, 20
30, 40
Dmitry.
Dr J R Stockton
individual.net>, Thu, 17 Jun 2010 10:55:52, Tim Streater
<timst...@waitrose.com> posted:
>
>Was it not "swap bytes" on an operand in the PDP-11? So you might say:
>
> swab R3 or swab (SP)
>
>for example to swap the bytes in register 3 or the top item on the stack.
>
Probably, since it is on page 10-13 of my copy of a handbook for the
LSI-11 series.
Did you ever consider 014747, which is MOV -(PC),-(PC) ?
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 7.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Command-prompt MiniTrue is useful for viewing/searching/altering files. Free,
DOS/Win/UNIX now 2.0.6; see <URL:http://www.merlyn.demon.co.uk/pc-links.htm>.
Evertjan.
>> However it ment "swap registers a and b"
>
> Was it not "swap bytes" on an operand in the PDP-11? So you might say:
>
> swab R3 or swab (SP)
>
> for example to swap the bytes in register 3 or the top item on the stack.
This could be, tim,
as my connection at Philips in that era was a PDP-11 programmer.
If so, it was NOT an 2650 opcode. ;-(
=============
The problem of storng a word highbyte first or lowbyte first was a mayor
headache, so the operand was very useful, methinks.
I think Steve Morse of 8086 fame, now a mayor programmer for Ellis Island
files and Jewish geneology <http://stevemorse.org/>, wrote about that in
one of his books of the late 1970's?
No, not this one: <http://stevemorse.com/>
Andrea Giammarchi
var
a = 1,
b = 2
;
with ({swap:null}) {
swap = a;
a = b;
b = swap;
}
which can be shortcutted to:
with ({swap:a}) {
a = b;
b = swap;
}
another missed opportunity via one of the most misunderstood operator
Regards,
Andrea Giammarchi
Dr J R Stockton
individual.net>, Sat, 19 Jun 2010 21:22:59, Tim Streater
<timst...@waitrose.com> posted:
>In article <DmRh$GGjw9...@invalid.uk.co.demon.merlyn.invalid>,
> Dr J R Stockton <repl...@merlyn.demon.co.uk> wrote:
>
>> In comp.lang.javascript message <timstreater-150A94.10555217062010@news.
>> individual.net>, Thu, 17 Jun 2010 10:55:52, Tim Streater
>> <timst...@waitrose.com> posted:
>>
>> >
>> >Was it not "swap bytes" on an operand in the PDP-11? So you might say:
>> >
>> > swab R3 or swab (SP)
>> >
>> >for example to swap the bytes in register 3 or the top item on the stack.
>> >
>>
>> Probably, since it is on page 10-13 of my copy of a handbook for the
>> LSI-11 series.
>>
>> Did you ever consider 014747, which is MOV -(PC),-(PC) ?
>
>Doesn't that cause your code to execute backwards, eating itself as it
>goes? Or something?
IIRC, it only creates, without eating. Each successive instruction
written is freshly written before the previous one. On a PDP-11,
hardware may stop it at address 0400 (?), but on an LSI-11 it may
overwrite the interrupt despatch area ...
--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (RFCs 5536/7)
Do not Mail News to me. Before a reply, quote with ">" or "> " (RFCs 5536/7)