[parenscript-devel] Bug with ==

szergling senatorzergling at gmail.com
Thu Mar 11 22:55:14 UTC 2010


Regarding the translation of code like (= x y z):

On 3/11/10, Vladimir Sedach <vsedach at 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.




More information about the parenscript-devel mailing list