As I mentioned before, the issue here is not just a fast "last". The issue
here is I find the design of Clojure "wrong", or confusing. That really
shakes my confidence in the whole system.
I am also not talking about implementations, which is a separate issue that
I don't know much yet
According to the book "Clojure Programming" by Chas, one of the Clojure's
principles is to "build on abstractions" and to separate abstractions from
concrete types. Now I have a little deeper contact with Clojure and my
impression is that is not the reality.
On Saturday, June 30, 2012 3:47:58 AM UTC-4, Craig Brozefsky wrote:
>
> Warren Lynn <wrn.l...@gmail.com> writes:
>
> > Although I have not yet looked at any of Clojure's internals yet, I
> > suspect the change won't be too difficult (for the right person). So
> I
> > hope/wish someone with enough knowledge, skills and influence will
> > agree with me and advocate a review of the design ("last" may not be
> > the only one with issues) and fix some of those things before things
> > get too messy down the road.
>
> Err, I don't think this is an issue of "design" let alone something
> worthy of getting a bit weepy about Clojure failing to be worthy of use
> in your production system as implied by your previous posts.
>
> Here is a version of last for clojure.core that will use peek on
> vectors.
>
> (def
> ^{:arglists '([coll])
> :doc "Return the last item in coll."
> :added "1.0"
> :static true}
> last (fn ^:static last [s]
> (if (vector? s)
> (peek s)
> (if (next s)
> (recur (next s))
> (first s)))))
>
> If the intent of specifying "in linear time" in the docstring was to
> guarantee the user that we would be looping over a sequence using
> first/next, then it should explicitely say so and not just imply it by
> mentioning linear time. Otherwise, I see the phrase as a warning, and
> not as a guarantee.
>
> David Nolen asked about drop-last and take-last and but-last.
>
> drop-last is defined as returning lazy sequences. A
> change to them that returned a vector with it's tail peeked off would be
> a change to the language. I am not so keen on that.
>
> take-last returns a seq, and it's not obvious after a whiskey just how
> to rewrite it to be more efficient for vectors and not just end up
> making it linear scaling on n for vectors.
>
> However, butlast is documented as returning a seq, so changing pop on a
> vector might have some performance advantage, and not change the
> outcomes of the function. Here is what that would look like.
>
> (def
> ^{:arglists '([coll])
> :doc "Return a seq of all but the last item in coll, in linear time"
> :added "1.0"
> :static true}
> butlast (fn ^:static butlast [s]
> (if (and (not (empty? s))
> (vector? s))
> (pop s)
> (loop [ret [] s s]
> (if (next s)
> (recur (conj ret (first s)) (next s))
> (seq ret))))))
>
> These changes don't really bring any new entanglement between
> clojure.core and the clojure.lang java objects -- because the language
> defines explicitely how vector conj/peek. However, going thru
> clojure.core and optimizing it based on knowledge of implementation in
> clojure.lang would be complecting - thus punishable by exile to the
> bitcoin mines.
>
>
> --
> Craig Brozefsky <cr...@red-bean.com>
> Premature reification is the root of all evil
>
--
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
