So you recommend that "last" should be only function that accepts
IPersistentStack *and* ISeqable and does the appopiate thing? Or are there
others?
On Thursday, June 28, 2012, Mark Engelberg wrote:
> On Thu, Jun 28, 2012 at 6:59 PM, Tamreen Khan
> <histor...@gmail.com<javascript:_e({}, 'cvml', '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<javascript:_e({}, 'cvml',
> '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 <javascript:_e({}, 'cvml',
> 'clojure%2bunsubscr...@googlegroups.com');>
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
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
