Makes sense for EQUALP. '===' is like both EQ and EQL (and EQUAL for strings, since those are immutable in JS). '==' is not quite EQUAL. One thing I did is define STRING= as being the same as '==='.
Send your implementation of EQUALP along, it would be a nice addition to the runtime library. Vladimir 2010/4/21 Daniel Gackle <[email protected]>: > I'll try this out later and report back. Since both CL and JS have a > strictness-hierarchy for equality (EQ,EQL,EQUAL,EQUALP vs. ==,===) it does > seem reasonable as a general strategy for PS to map between these two > hierarchies. > If I understand correctly, the plan you're describing is to map EQ and EQL > to ===, EQUAL and EQUALP to ==. This raises the question, why define four > different equality predicates in PS to begin with? Perhaps it would be > better to just have two? (Say EQ for === and EQUAL for ==.) > One reason I ask is that we already have a PS implementation of EQUALP that > does deep equality testing like CL's EQUALP does. In other words, (ps > (equalp '(a b (c)) '(a b (c)))) evaluates to true in JS. Obviously this > requires a runtime library function. But we've found it very useful, > especially for unit tests that have complex data structures to compare. Our > PS EQUALP also compares JS objects so that, for example, > equalp({a:123},{a:123}) returns true. I'd be happy to contribute our > implementation to PS if it would be helpful, but my point is more generally > that the name EQUALP should probably be reserved for something that has > these semantics -- partly because that's what it means in CL and partly > because it's so damn useful. Thoughts? > > > On Wed, Apr 21, 2010 at 3:09 PM, Vladimir Sedach <[email protected]> wrote: >> >> 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 > > > _______________________________________________ > 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
