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.
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
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
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
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
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@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@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
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
parenscript-devel@common-lisp.net
-
Daniel Gackle -
Vladimir Sedach