[parenscript-devel] Equality issues

[Vladimir Sedach]

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