Regarding the translation of code like (= x y z): On 3/11/10, Vladimir Sedach <[email protected]> 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 [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
