Bobby: Thanks for confirming my sanity here. But I have a different opinion on the "attractive nuisance" label on "last" function. Sure if you call "last" on an infinite sequence that will not work (the program will get stuck?), but it is no more dangerous than other dynamic part of the language. Think about a higher order function, a function that takes another function as an argument, isn't that much more dangerous? I mean, you don't even know what kind of function people may throw into it, and the damage could be bigger (for example, it may even wipe out you hard drive). As a dynamic language gives high level of freedom and abstraction power, the programmer needs to take certain responsibilities too, because the compiler will catch much less errors than a statically typed language.
So I still think "last" is a very useful function and worth fixing. Ideally, if a sequence can be checked if it is infinite or not so "last" can throw an exception when not applicable, but that may not be feasible with lazy sequences. And again I feel the responsibility should be more on the programmer's side. On Friday, June 29, 2012 9:23:09 PM UTC-4, Bobby Eickhoff wrote: > > 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
