On Apr 29, 2:17 am, Mark Engelberg <mark.engelb...@gmail.com> wrote: > On Wed, Apr 28, 2010 at 10:49 PM, Douglas Philips <d...@mac.com> wrote: > > What is the purpose, goal, design-rationale of not making seq-contains? fast > > on maps or sets? > > I think Rich's point is that if seq-contains? is sometimes fast and > sometimes slow, then it makes it harder to reason about a program that > uses seq-contains?. Is this one of the "slow" usages, or one of the > "fast" usages? On the other hand, with the current plan, you know > exactly what performance you're getting. contains? will always be > fast on sets and maps (albeit returning meaningless results for lists, > and counterintuitive results for vectors). seq-contains? always does > a linear search. So if you see seq-contains? in your code, this > serves as a big red flag that either you should be using a set data > structure and contains?, or you better be sure your sequence is > relatively small.
I don't fully agree with the reasoning here. It seems clear that part of what contains? means should be "will be fast," so contains? must only be available for types where this performance can be guaranteed. What is less clear to me is whether part of what seq-contains? means should be "will be slow/will be implemented as an O(n) sequential search," or whether it should be "may be slow." I'm not convinced that "may be slow" doesn't raise enough of a warning flag and makes reasoning about a program harder than does "will be slow" -- and "will be implemented as..." smells bad. -- 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
