Unfortunately our code is still broken because of another variant of this business of null and undefined. The trouble comes when the two are being compared through EQUAL. That is, there are various expressions scattered through our code like this:<div>

<br></div><div>(equal a b)</div><div><br></div><div>and sometimes A is null and B undefined (or vice versa). Such expressions used to evaluate to true, now they're false, and it's breaking our code.</div><div><br>

</div><div>I'm loath to change this to conform to the strict semantics of === because, as I mentioned earlier, we've written our PS code to conflate null and undefined, and this has worked well. For example, it allows you to not bother with explicit "return null"s at the end of functions. To switch to the strict semantics would require our code to keep track of what's null and what's undefined in a way that would not provide any gain, and would be brittle and error-prone.</div>

<div><br></div><div>Daniel</div><div><br></div><div><br></div><div><br><div class="gmail_quote">On Tue, Apr 20, 2010 at 3:43 PM, Vladimir Sedach <span dir="ltr"><<a href="mailto:vsedach@gmail.com">vsedach@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">You're right, that absolutely makes sense. I've pushed a fix.<br>
<br>
It's interesting to note that this is the only place in the code<br>
Parenscript generates where the semantics of '==' (as opposed to<br>
'===') make sense.<br>
<br>
Vladimir<br>
<br>
2010/4/19 Daniel Gackle <<a href="mailto:danielgackle@gmail.com">danielgackle@gmail.com</a>>:<br>
<div><div></div><div class="h5">> The array literals fix worked, thanks. Next up: the changes around equality<br>
> are a problem.<br>
> Specifically, the NULL operator, which used to evaluate to true on both null<br>
> and undefined, now applies strict equality, meaning that (null undefined) is<br>
> false. Since we use the NULL operator in a great many places precisely to<br>
> check whether something is null or undefined, this change breaks our code.<br>
> In general, I've found it to be good to conflate null and undefined in most<br>
> of our PS code; it simplifies things and works fine. So I guess we have to<br>
> go on record as protesting this change... especially since there already<br>
> existed ways to distinguish null from undefined in the minority case when<br>
> it's needed.<br>
> Others' thoughts?<br>
> Dan<br>
> p.s. I haven't looked closely at the other implications of the equality<br>
> changes, because the NULL issue is such a big one that I thought I'd start<br>
> there.<br>
</div></div>> _______________________________________________<br>
> parenscript-devel mailing list<br>
> <a href="mailto:parenscript-devel@common-lisp.net">parenscript-devel@common-lisp.net</a><br>
> <a href="http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel" target="_blank">http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel</a><br>
><br>
><br>
<br>
_______________________________________________<br>
parenscript-devel mailing list<br>
<a href="mailto:parenscript-devel@common-lisp.net">parenscript-devel@common-lisp.net</a><br>
<a href="http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel" target="_blank">http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel</a><br>
</blockquote></div><br></div>