[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