Personally I think nth is broken and should throw an exception when passed nil (which should be interpreted as an empty sequence)
=> (nth nil 10) nil => (nth '() 10) IndexOutOfBoundsException clojure.lang.RT.nthFrom (RT.java:885) => (nth [] 10) IndexOutOfBoundsException clojure.lang.PersistentVector.arrayFor (PersistentVector.java:157) We want to throw exceptions with invalid arguments surely? Otherwise errors just propagate and it gets harder to trace root causes of bugs. Following this logic, rand-nth should throw an exception in all these cases too. On Thursday, 1 October 2015 06:11:36 UTC+8, Marc O'Morain wrote: > > I think Mailbox app might have messed with the quoting in my last reply. I > hope it makes sense. > > I'm not suggesting that the function be changed - Clojure's API > compatibility between versions is amazing and a fine example of great > engineering. > > Reading other people's input on this thread has made it clear to my what I > find surprising - rand-nth does not behave like `first` when called on an > empty collection, and in my mind asking for the first element of a sequence > and asking for a random element of that sequence are similar operations. > > I do see the point of view that nth throws on out-of-bounds access, so > rand-nth should too, but in that case I would expect rand-nth to throw too. > > I would like to see that subtlety mentioned in the doc string. > > Thanks Alex & all! > > > > On Wed, Sep 30, 2015 at 3:14 PM, Alex Miller <al...@puredanger.com > <javascript:>> wrote: > >> rand-nth cannot return a random element if there are no elements to >> return, so I do not find this surprising. Returning nil would be an invalid >> answer in my opinion. >> >> The rand-nth doc string implies that rand-nth will inherit the semantics >> of nth for the specified collection. nth will generally throw on an invalid >> index (and all indexes are invalid for an empty collection). >> >> For nil, the docstring for nth does not mention nil explicitly, so I >> would treat this as undefined behavior unless you consider it as a >> degenerate sequence. >> >> The code (in RT.nthFrom()) explicitly handles this case and effectively >> treats nil as an infinite indexed source of nils, rather than as an empty >> sequence. In my own opinion (but maybe not Rich's), it seems to make more >> sense to take the sequence interpretation and say that on nil, nth should >> throw instead. >> >> So that might be a valid ticket. I'm not sure what, if any, negative >> consequences would arise out of existing uses of nth that rely on this >> behavior though. Given the number of things built on nth, it may be >> impossible to change this even if it made sense to. >> >> Alex >> >> On Wednesday, September 30, 2015 at 6:38:49 AM UTC-5, Marc O'Morain wrote: >>> >>> Hi all, >>> >>> I was surprised by the fact that rand-nth thrown when called on an empty >>> collection - see http://dev.clojure.org/jira/browse/CLJ-925 >>> <http://www.google.com/url?q=http%3A%2F%2Fdev.clojure.org%2Fjira%2Fbrowse%2FCLJ-925&sa=D&sntz=1&usg=AFQjCNFpBhBI2wA5LnBRCiAP8oYyF5HdOg> >>> >>> This behaviour is strange, since passing nil to rand-nth returns nil, >>> whereas in my experience, other Clojure functions treat nil and empty >>> collections in the same way (compare with next/rest/first, etc). >>> >>> http://dev.clojure.org/jira/browse/CLJ-925 was marked as Completed >>> without comment – is this the intended behaviour? If so, would you accept a >>> patch to update the docstring to make it clear that the function will throw >>> an exception when passed an empty collection? >>> >>> Thanks, >>> >>> Marc >>> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com >> <javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
