(let ((x 10) (y 10) (z 10)) (= x y z))
is true Common Lisp, but the PS equivalent...
var x = 10; var y = 10; var z = 10; x == y == z;
... is false. The left operand of the second == is actually x==y, which evalutes to true, and true==z of course is false. An equivalent in CL might be:
(equal (equal x y) z)
Perverse side note: the above example doesn't work if you assign 1 to the variables because in JS, the following is true:
1 == true
I didn't know this. JS still manages to shock me sometimes.
Daniel
On Tue, Mar 2, 2010 at 10:59 PM, Daniel Gackle danielgackle@gmail.com wrote:
Perverse side note: the above example doesn't work if you assign 1 to the variables because in JS, the following is true:
1 == true
I didn't know this. JS still manages to shock me sometimes.
That is why you always should use === instead of == in Javascript.
1 == true is true 1 === true is false
http://rayfd.wordpress.com/2007/03/18/really-understanding-javascripts-equal...
/Henrik Hjelte
I can't find the relevant thread now, but I'm sure you brought this issue up over a year ago. The code generated is supposed to be:
var x = 10; var y = 10; var z = 10; var _cmp1 = y; x == _cmp1 && _cmp1 == z;
The problem is that transformation is currently implemented as a hack on top of the compiler, and "=" wasn't one of the symbols in the special list that gets "corrected."
I've pushed a patch that adds a fix to the hack, but I'm going to rework the implementation later.
One issue this raises is order of evaluation. Doing that transformation on n expressions and preserving left-to-right evaluation order means introducing n temporary variables in the general case. This problem also comes up when defining setf expanders for places. At this point Parenscript might as well adopt the Scheme policy of "order of argument evaluation is undefined" officially.
Also Henrik brings up a good point - the "=" form should expand to "===." "==" is more like EQUAL.
Vladimir
2010/3/2 Daniel Gackle danielgackle@gmail.com:
(let ((x 10) (y 10) (z 10)) (= x y z))
is true Common Lisp, but the PS equivalent...
var x = 10; var y = 10; var z = 10; x == y == z;
... is false. The left operand of the second == is actually x==y, which evalutes to true, and true==z of course is false. An equivalent in CL might be:
(equal (equal x y) z)
Perverse side note: the above example doesn't work if you assign 1 to the variables because in JS, the following is true:
1 == true
I didn't know this. JS still manages to shock me sometimes.
Daniel
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
Regarding the translation of code like (= x y z):
On 3/11/10, Vladimir Sedach vsedach@gmail.com wrote:
I can't find the relevant thread now, but I'm sure you brought this issue up over a year ago. The code generated is supposed to be:
var x = 10; var y = 10; var z = 10; var _cmp1 = y; x == _cmp1 && _cmp1 == z;
The problem is that transformation is currently implemented as a hack on top of the compiler, and "=" wasn't one of the symbols in the special list that gets "corrected."
I've pushed a patch that adds a fix to the hack, but I'm going to rework the implementation later.
One issue this raises is order of evaluation. Doing that transformation on n expressions and preserving left-to-right evaluation order means introducing n temporary variables in the general case. This problem also comes up when defining setf expanders for places. At this point Parenscript might as well adopt the Scheme policy of "order of argument evaluation is undefined" officially.
I will find "undefined order of evaluation" to be very surprising for a Common Lisp translator.
Do people find conciseness more important than the order of evaluation?
Also Henrik brings up a good point - the "=" form should expand to "===." "==" is more like EQUAL.
Just wondering, why does == or === get this treatment but not the other operators like
(< 4 x 12) ?
Were you planning to support those later in your rewrite?
Yong.
Hi Yong,
< I will find "undefined order of evaluation" to be very surprising for a Common Lisp translator. >
You're right about that, but PS isn't exactly a CL translator: it's a mostly-correct mapping of a subset of CL to Javascript. The key terms here are "mostly" and "subset". This is what allows the generated JS to remain reasonably efficient and reasonably readable, i.e. suitable for production applications that run in today's web browsers. There's no way to make PS into a strictly correct CL translator without sacrificing these goals; the impedance mismatch between CL and JS makes that too difficult. So there's a judgment call to be made every time one of these cases comes up: how much correctness and compatibility with CL should we go for, in order to keep the generated code well-suited to the browser environment? Put differently, how do we carve out precisely the subset of CL that PS should support?
If you understand this philosophy behind PS (a pompous use of the word "philosophy", but you know what I mean), you might still disagree about how to handle (= x y z), but perhaps on slightly different grounds.
Daniel
On Thu, Mar 11, 2010 at 3:55 PM, szergling senatorzergling@gmail.comwrote:
Regarding the translation of code like (= x y z):
On 3/11/10, Vladimir Sedach vsedach@gmail.com wrote:
I can't find the relevant thread now, but I'm sure you brought this issue up over a year ago. The code generated is supposed to be:
var x = 10; var y = 10; var z = 10; var _cmp1 = y; x == _cmp1 && _cmp1 == z;
The problem is that transformation is currently implemented as a hack on top of the compiler, and "=" wasn't one of the symbols in the special list that gets "corrected."
I've pushed a patch that adds a fix to the hack, but I'm going to rework the implementation later.
One issue this raises is order of evaluation. Doing that transformation on n expressions and preserving left-to-right evaluation order means introducing n temporary variables in the general case. This problem also comes up when defining setf expanders for places. At this point Parenscript might as well adopt the Scheme policy of "order of argument evaluation is undefined" officially.
I will find "undefined order of evaluation" to be very surprising for a Common Lisp translator.
Do people find conciseness more important than the order of evaluation?
Also Henrik brings up a good point - the "=" form should expand to "===." "==" is more like EQUAL.
Just wondering, why does == or === get this treatment but not the other operators like
(< 4 x 12) ?
Were you planning to support those later in your rewrite?
Yong.
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
parenscript-devel@common-lisp.net
-
Daniel Gackle -
Henrik Hjelte -
szergling -
Vladimir Sedach