On 2010 Apr 28, at 5:32 PM, Meikel Brandmeyer wrote:
On Wed, Apr 28, 2010 at 05:26:46PM -0400, Douglas Philips wrote:
How is having an optimized version of seq-contains? for sets/maps
any different from what Stuart showed in his video, where reduce can
have a specialization that is faster on some types?
A faster reduce is still O(N). If you need fast lookup use the correct
data structure. If you do linear search it's gonna be slow, so make it
clear in the code! This makes the developer aware of the implications.
Stuart's comment was to not use seq-contains? on maps or sets.
There is no reason that it cannot be the same speed as contains? if a
set or map is passed in.
Wasn't the whole point of having sequences as an abstraction to get
away from all the cruft that traditional lisp had built up around
concrete types? Why go back to that here? Can't protocols handle
optimizing this case?
If some function I call uses seq-contains? (so that it can get all the
wonderful seq-ness abstractness clojure offers) I should have to know
that internal detail and not pass in a map or set? or worse, fail to
get an optimization in that case? C'mon, this should be an easy
protocol win (or maybe I don't really understand the limits on what
protocols can do.)
-Doug
--
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
