On 2010 Apr 28, at 6:10 PM, Stuart Halloway wrote:
The "seq" in "seq-contains?" says "I want a sequential search."
Protocols *could* make this do something different, but that would
violate the contract of this function.
How would having it work faster if passed a set or map violate that?
There is no ordering guarantee for those types. Is this a contract to
be slow? Is there something about the comparison being done by seq-
contains? that is different from contains? would seq-contains? somehow
return a different answer? And what about the sorted collections,
where seq-contains? could be fast if the value sought was smaller or
larger than the values contained?
I don't see the distinction(s) you're trying to make here.
Another way to put it: If you wrote a protocol to pick a fast
implementation based on type, then seq-contains? would be the fn
that the protocol would call if it couldn't find anything faster.
There have to be primitive things somewhere...
If so, then why isn't there a vector-first and a list-first and abc-
first that I can use when I 'know' what type I'm working with?
Aren't they all subsumed under 'first' because Clojure understands
that premature optimization based on concrete types was the wrong
thing to do? At least that is the message I got from Rich's videos
explaining why tying all of the "old" lisp goodness to concrete types
was wrong (unnecessarily limiting).
-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
