Perhaps place them inside a protocol, where core supplies implementations for ISeq only? This would make it easier to extend efficient behavior to other types without placing a big burden on core.
On Fri, Jun 29, 2012 at 3:05 PM, David Nolen <dnolen.li...@gmail.com> wrote: > On Fri, Jun 29, 2012 at 5:17 PM, Mark Engelberg > <mark.engelb...@gmail.com> wrote: > > It is clear that some collections *could* support a more efficient last. > > Anything with random access. Anything that supports rseq (e.g., sorted > > collections). > > And what does overloading last in this way mean for drop-last, > take-last, but-last? All sequence functions. > > David > > -- > 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 > -- Sam Ritchie, Twitter Inc 703.662.1337 @sritchie09 (Too brief? Here's why! http://emailcharter.org) -- 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
