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.