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?
Specializations are available where there is a clear use case, e.g.
contains?, peek (instead of last), disj, etc.
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).
Tying to concrete types is limiting. *Never* having special purpose
fns that know about performance characteristics is also limiting.
contains?/seq-contains? mark a divide where it is very easy for a
language to quietly help programmers do the wrong thing.
Stu
-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
--
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
