[parenscript-devel] Equality issues

[Vladimir Sedach]

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
>
>