[parenscript-devel] Bug with ==

Vladimir Sedach vsedach at gmail.com
Wed Mar 10 15:23:06 UTC 2010


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 at 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 at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>
>




More information about the parenscript-devel mailing list