[parenscript-devel] Equality issues

[Daniel Gackle]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/parenscript-devel/attachments/20100421/9d862d36/attachment.html>