[parenscript-devel] What should PS LOOP do with null collections?
I don't know if anyone other than us is using PS LOOP, but we use it heavily since our application is very loop-intensive. A continual source of bugs is looping over a null collection. Say BAR is null. The following will crash: (ps (loop :for foo :in bar :do (baz foo))) ...because the code expands to include (length bar). This is particularly annoying if you're running the code in CL as well, where looping over a null collection is just fine. We've been dealing with this like so: (ps (loop :for foo :in (or bar '()) :do (baz foo))) ... but this is ugly and more importantly very brittle, since it means tracking down every crash case-by-case. My question: what does everybody think about making PS LOOP accept null collections and just do nothing in that case? Something about this bothers me. It goes against the philosophy of PS, which declines to pretend that JS arrays are Lisp lists (something I fully agree with). But I'm inclined to make an exception in this case because the strict approach is so painful. And this of course raises the analogous question for any PS versions of MAPCAR, MAPC, etc. Daniel
So what you're proposing is making the implicit sequence type be (or array nil), where nil is treated like a zero-length array? I think that's a good idea, it will make a lot of things simpler. Vladimir 2010/7/12 Daniel Gackle <danielgackle@gmail.com>:
I don't know if anyone other than us is using PS LOOP, but we use it heavily since our application is very loop-intensive. A continual source of bugs is looping over a null collection. Say BAR is null. The following will crash: (ps (loop :for foo :in bar :do (baz foo))) ...because the code expands to include (length bar). This is particularly annoying if you're running the code in CL as well, where looping over a null collection is just fine. We've been dealing with this like so: (ps (loop :for foo :in (or bar '()) :do (baz foo))) ... but this is ugly and more importantly very brittle, since it means tracking down every crash case-by-case. My question: what does everybody think about making PS LOOP accept null collections and just do nothing in that case? Something about this bothers me. It goes against the philosophy of PS, which declines to pretend that JS arrays are Lisp lists (something I fully agree with). But I'm inclined to make an exception in this case because the strict approach is so painful. And this of course raises the analogous question for any PS versions of MAPCAR, MAPC, etc. Daniel _______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
That's right. I wonder if there are other places where this refinement should be introduced? On Mon, Jul 12, 2010 at 8:13 AM, Vladimir Sedach <vsedach@gmail.com> wrote:
So what you're proposing is making the implicit sequence type be (or array nil), where nil is treated like a zero-length array? I think that's a good idea, it will make a lot of things simpler.
Vladimir
2010/7/12 Daniel Gackle <danielgackle@gmail.com>:
I don't know if anyone other than us is using PS LOOP, but we use it heavily since our application is very loop-intensive. A continual source of bugs is looping over a null collection. Say BAR is null. The following will crash: (ps (loop :for foo :in bar :do (baz foo))) ...because the code expands to include (length bar). This is particularly annoying if you're running the code in CL as well, where looping over a null collection is just fine. We've been dealing with this like so: (ps (loop :for foo :in (or bar '()) :do (baz foo))) ... but this is ugly and more importantly very brittle, since it means tracking down every crash case-by-case. My question: what does everybody think about making PS LOOP accept null collections and just do nothing in that case? Something about this bothers me. It goes against the philosophy of PS, which declines to pretend that JS arrays are Lisp lists (something I fully agree with). But I'm inclined to make an exception in this case because the strict approach is so painful. And this of course raises the analogous question for any PS versions of MAPCAR, MAPC, etc. Daniel _______________________________________________ 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
participants (2)
-
Daniel Gackle -
Vladimir Sedach