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 <vsedach@gmail.com> 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 <danielgackle@gmail.com>:
> 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 <vsedach@gmail.com> 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 <danielgackle@gmail.com>:
>> > 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
>> > parenscript-devel@common-lisp.net
>> > http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>> >
>> >
>>
>> _______________________________________________
>> parenscript-devel mailing list
>> parenscript-devel@common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>
>
> _______________________________________________
> parenscript-devel mailing list
> parenscript-devel@common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>
>

_______________________________________________
parenscript-devel mailing list
parenscript-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel