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
