On Thu, Jun 28, 2012 at 6:59 PM, Tamreen Khan <histor...@gmail.com> wrote:
> Here's a somewhat old but still generally useful article on how Clojure > vectors are implemented: > http://blog.higher-order.net/2009/02/01/understanding-clojures-persistentvector-implementation/ > > > Vectors are optimized for random access, whereas lists are optimized for > going through from the beginning to the end, which is exactly what the last > function does. > > > This doesn't really address the underlying question. nth is a good example of a function that is fast for vectors, strings, and arrays, and only for lists uses the slower sequential implementation. There's no technical reason that last couldn't do the same, dispatching on the underlying type to have a more efficient implementation for data types that support it. The real reason is this: With the glaring exception of nth, Clojure tends to eschew functions with a fast path and a slow path, because programmers shouldn't have to do deep semantic analysis of their code to figure out which will get chosen. In this case, however, we're talking about a function that is currently always slow. Surely it would be a win to make it have a faster path in a large number of cases, right? Well, the argument against that is eventually people would start to rely on it being fast for so many collection types, and then get burned when somehow their collection accidentally gets turned into a seq before last is called on it. The theory is that it's better to force people to use a different function call, namely peek, to retrieve the last element quickly from a vector. Honestly though, despite David Nolen's claim that this design decision will be obvious if you've coded enough Clojure, I've been programming in it for around 3-1/2 years, and I think the argument behind this design decision is a relatively weak one, so you are not making an unreasonable request. In fact, the more I code in Clojure, the more I see that there are a number of core functions that require significant semantic analysis of the surrounding context to know how they will behave. Either Clojure trusts that programmers can make determinations about the types of their collections or it doesn't. Which is it? Well, I'd argue there's a large body of evidence that under Clojure's current design, it's clear that you better know what you're doing. If that's the case, why not go ahead and make last fast when it can be fast? Nevertheless, I hope I've clarified the reasoning behind the current design. Early Clojure design decisions have a lot of inertia, so as David pointed out, this is very unlikely to change. -- 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
