On Oct 3, 9:27 am, Dimitre Liotev <[EMAIL PROTECTED]> wrote:
> Rich Hickey <[EMAIL PROTECTED]> writes:
>
> [..]
>
> > Possible models are CL's member, which works on lists and returns the
> > tail beginning with the found item, and position, which works on
> > sequences and returns the index if found. There are also versions of
> > each that use predicate functions.
>
> >http://www.lispworks.com/documentation/HyperSpec/Body/f_mem_m.htm
> >http://www.lispworks.com/documentation/HyperSpec/Body/f_pos_p.htm
>
> > I'm open to variants of either or both of these, and have left the
>
> I'd like to have both. These are very useful functions and if their
> addition wouldn't be in conflict with any other aspects of Clojure, then
> why not include them?
>
The main reason, which I discussed with Hans on IRC, is that they have
bad performance characteristics. Lists and vectors make for bad sets,
and alists make for bad maps, with linear lookup times. Clojure has
real sets and maps, with reader and library support.
With those functions in place, people may come from CL and Scheme and
continue to use them where they are not appropriate; Clojure has
better, more scalable alternatives.
filter is already a lazy version of member-if, and automates the
pattern of searching again with the last found tail.
So maybe filter= would obviate the need for member, although there is
a very cool idiom for using sets as equality filters which works for
everything except nil and false:
(filter #{x} coll)
Which just leaves us without position/index-of
Rich
--~--~---------~--~----~------------~-------~--~----~
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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
