> I'm guessing there are similar bugs in drop, take, and so forth with > large n and large (or infinite) seqs. They should all be fixed.
The other fns are ok, thanks to their separate heritage. drop, take, et al are sequence functions, and proceed iteratively. nth is of a different lineage. It was designed to target collections that support constant time-lookup. Collection-y things in the Java world provide APIs that take int, not long, because that is what arrays do at the bottom. FWIW, Sun (now Oracle) considers this a low-priority problem: http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=5d84e2e6a65a5ffffffffc03eacaafb73e91?bug_id=4963452. nth has a doc bug: it should be documented as a function of a collection and a 32-bit int. A patch updating the docstring, and even enforcing it with an IllegalArgumentException, would be welcome. (George: want to write your first patch? :-) ) Stu Stuart Halloway Clojure/core http://clojure.com -- 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
