Warren, you're on the right track with your alternative design: Intuitively and ideally, "last" should return the last element of a finite, ordered collection. But Clojure's "last" operates on sequences, not collections. This is problematic because sequences can be (effectively) infinite. Calling "last" on an arbitrary sequence is, therefore, dubious at best. It's what Doug Crockford might call an attractive nuisance: sometimes useful, but dangerous. So "last" isn't a function I would spend alot of time trying to fix.
There is historical precedent for Clojure's "last" function. For example, see Haskell's "last" function in Data.List. Historical precedent doesn't justify the design, but it helps explain how we got here. Bobby On Friday, June 29, 2012 4:34:04 PM UTC-4, Warren Lynn wrote: > > Even not a single action is taken because of this thread, I still would > not consider the thread fruitless. It helped me (and maybe others) > understand the issue better. > > My point was: you need a clear documentation on a coherent, consistent > abstraction, and let the programmer to understand. Just clear documentation > is not enough. You can document a very messy system in clear documentation > (maybe the US tax code?). > > Here, we are having both "peek" and "last", which is not coherent to me. > consider the documentation on an alternative design: > > last: get the last element from an ordered collection. for queues and > linked lists, it takes linear time. for vectors, it takes constant time. > > and get rid of "peek" (we already have "first" for linked list and queues, > right?) > > Which one is cleaner? > -- 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
