What makes this worse is that you don't have control of whether other JS functions return null or undefined.
What I think would make sense (and had in mind as an option to do before) is make EQUALP and EQUAL compile to '==', and all the other equality predicates to '==='. I've pushed a patch that does that. Let me know if that works for your codebase. A lot of code is probably going to get affected by these changes, but IMO it's the right thing to do. Vladimir 2010/4/21 Daniel Gackle <[email protected]>: > 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: > (equal a b) > 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. > 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. > Daniel > > > On Tue, Apr 20, 2010 at 3:43 PM, Vladimir Sedach <[email protected]> wrote: >> >> You're right, that absolutely makes sense. I've pushed a fix. >> >> It's interesting to note that this is the only place in the code >> Parenscript generates where the semantics of '==' (as opposed to >> '===') make sense. >> >> Vladimir >> >> 2010/4/19 Daniel Gackle <[email protected]>: >> > The array literals fix worked, thanks. Next up: the changes around >> > equality >> > are a problem. >> > Specifically, the NULL operator, which used to evaluate to true on both >> > null >> > and undefined, now applies strict equality, meaning that (null >> > undefined) is >> > false. Since we use the NULL operator in a great many places precisely >> > to >> > check whether something is null or undefined, this change breaks our >> > code. >> > In general, I've found it to be good to conflate null and undefined in >> > most >> > of our PS code; it simplifies things and works fine. So I guess we have >> > to >> > go on record as protesting this change... especially since there already >> > existed ways to distinguish null from undefined in the minority case >> > when >> > it's needed. >> > Others' thoughts? >> > Dan >> > p.s. I haven't looked closely at the other implications of the equality >> > changes, because the NULL issue is such a big one that I thought I'd >> > start >> > there. >> > _______________________________________________ >> > parenscript-devel mailing list >> > [email protected] >> > http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel >> > >> > >> >> _______________________________________________ >> parenscript-devel mailing list >> [email protected] >> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel > > > _______________________________________________ > parenscript-devel mailing list > [email protected] > http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel > > _______________________________________________ parenscript-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
