On 4/29/2010 6:49 PM, Michael Gardner wrote:
+1. I can't imagine any use case for looking up a whole [key, value] pair in a
hash-map.
Agreed. The whole point of a map is to provide key-based lookup.
Iterating over all (key, value) pairs in the map makes sense,
not so much looking for one in
On Apr 30, 2010, at 14:33 , Rich Hickey wrote:
'contains?' and 'get' abstract over fast lookup. They are polymorphic on the
collection type and on the nature of the looked-up thing. For maps the
looked-up thing is a key, for sets: a value, for vectors, strings and arrays:
an index.
If contains? is a sensible name for that function, then surely
seq-contains? cannot be a sensible name for a function which checks
a totally different sort of containment?
Also, if it is possible to view seq-contains? as a sensible enough
name for a core library function with sequential
On Apr 29, 2010, at 4:21 AM, ataggart wrote:
I know it won't matter, but for posterity if nothing else...
Functions named contains-key? and contains-val? would make a lot more
sense to me than the current contains? and new seq-contains?. Anyone
looking at contains-val? should expect it to be
2010/4/30 Rich Hickey richhic...@gmail.com:
On Apr 29, 2010, at 4:21 AM, ataggart wrote:
I know it won't matter, but for posterity if nothing else...
Functions named contains-key? and contains-val? would make a lot more
sense to me than the current contains? and new seq-contains?. Anyone
On Apr 29, 2010, at 2:19 PM, MarkSwanson wrote:
On Apr 29, 4:21 am, ataggart alex.tagg...@gmail.com wrote:
I know it won't matter, but for posterity if nothing else...
Functions named contains-key? and contains-val? would make a lot more
sense to me than the current contains? and new
Hi,
On Thu, Apr 29, 2010 at 7:48 AM, Meikel Brandmeyer m...@kotka.de wrote:
On 29 Apr., 01:38, Mark Engelberg mark.engelb...@gmail.com wrote:
1. Don't include seq-contains? The behavior you want can usually be
achieved by using (some #{item} coll). Disadvantage - if you're
testing to
On Fri, Apr 30, 2010 at 4:33 AM, Rich Hickey richhic...@gmail.com wrote:
On Apr 29, 2010, at 4:21 AM, ataggart wrote:
Functions named contains-key? and contains-val? would make a lot more
sense to me than the current contains? and new seq-contains?. Anyone
looking at contains-val? should
On Fri, Apr 30, 2010 at 5:18 AM, Laurent PETIT laurent.pe...@gmail.com wrote:
While it sounds soo evident now that you say that explicitly ( the
contains? / get pair ), it may be good to reflect that in the docs of
the functions rather than just keep this knowledge here ?
Agreed. This
On Apr 30, 4:33 am, Rich Hickey richhic...@gmail.com wrote:
People don't consider sets, vectors, arrays or strings to have 'keys'.
But, like maps, they all support fast lookup of some sort.
But of course we do. I point to the doc for contains? and get:
Usage: (contains? coll key)
Returns
On 2010 Apr 30, at 7:33 AM, Rich Hickey wrote:
People don't consider sets, vectors, arrays or strings to have
'keys'.
That is not consistent with the documentation:
Sets: http://clojure.org/data_structures:
Sets support 'removal' with disj, as well as contains? and get, the
latter
On Apr 30, 2010, at 6:33 AM, Rich Hickey wrote:
Would contains-val? be fast for sets? As a user of sets, I consider them
collections of values, and I absolutely would reach for contains-val? in any
library that had it, for use with sets. If so, and I used contains-val?, and
I moved code
On Apr 29, 3:21 am, ataggart alex.tagg...@gmail.com wrote:
Functions named contains-key? and contains-val? would make a lot more
sense to me than the current contains? and new seq-contains?.
Amen. Even independent of any performance expectations.
--
You received this message because you are
Phil Hagelberg p...@hagelb.org writes:
Actually I do consider sets to have keys, since internally they are
implemented using maps, so the exact same semantics apply for their
lookup. They're just maps where the key and value are the same thing:
But that implementation is one of convenience,
Clojure embraces this laziness:
user= (get #{:foo :bar} :foo)
:foo
'get uses a key to return a value. A vector is not a map is not a
set, but all of them can have their values accessed in constant-time
using a key.
On Apr 30, 3:14 pm, Steven E. Harris s...@panix.com wrote:
Phil Hagelberg
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
I know it won't matter, but for posterity if nothing else...
Functions named contains-key? and contains-val? would make a lot more
sense to me than the current contains? and new seq-contains?. Anyone
looking at contains-val? should expect it to be O(n). The only
effective difference would be
On Apr 29, 2010, at 1:57 AM, Meikel Brandmeyer wrote:
Hi,
On 29 Apr., 01:43, Stuart Halloway stuart.hallo...@gmail.com wrote:
I'll wait for Rich to maybe chime in on seq-contains?. Other than
seq-
contains? are people liking the new fns? Anybody having issues we
didn't anticipate?
I was
I like this proposal. I'd make contains? an alias for contains-key?
with a deprecation warning, and just forget about seq-contains? in
favor of contains-val?
On Thursday, April 29, 2010, ataggart alex.tagg...@gmail.com wrote:
I know it won't matter, but for posterity if nothing else...
2010/4/29 Mark J. Reed markjr...@gmail.com:
I like this proposal. I'd make contains? an alias for contains-key?
with a deprecation warning, and just forget about seq-contains? in
favor of contains-val?
This makes a lot of sense to me.
(and have, as suggested by ataggart, contains-key?
Thinking about this one.
I like this proposal. I'd make contains? an alias for contains-key?
with a deprecation warning, and just forget about seq-contains? in
favor of contains-val?
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this
On 2010 Apr 29, at 2:17 AM, Mark Engelberg wrote:
On Wed, Apr 28, 2010 at 10:49 PM, Douglas Philips 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
On 2010 Apr 29, at 4:21 AM, ataggart wrote:
Functions named contains-key? and contains-val? would make a lot more
sense to me than the current contains? and new seq-contains?. Anyone
looking at contains-val? should expect it to be O(n). The only
effective difference would be that the test
On 2010 Apr 29, at 7:52 AM, Laurent PETIT wrote:
2010/4/29 Mark J. Reed markjr...@gmail.com:
I like this proposal. I'd make contains? an alias for contains-key?
with a deprecation warning, and just forget about seq-contains? in
favor of contains-val?
This makes a lot of sense to me.
(and
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
(send contains-val? inc)
On Apr 29, 9:06 am, Douglas Philips d...@mac.com wrote:
On 2010 Apr 29, at 4:21 AM, ataggart wrote:
Functions named contains-key? and contains-val? would make a lot more
sense to me than the current contains? and new seq-contains?. Anyone
looking at contains-val?
On Apr 29, 2010, at 3:21 AM, ataggart wrote:
I know it won't matter, but for posterity if nothing else...
Functions named contains-key? and contains-val? would make a lot more
sense to me than the current contains? and new seq-contains?. Anyone
looking at contains-val? should expect it to
On Apr 29, 4:21 am, ataggart alex.tagg...@gmail.com wrote:
I know it won't matter, but for posterity if nothing else...
Functions named contains-key? and contains-val? would make a lot more
sense to me than the current contains? and new seq-contains?. Anyone
looking at contains-val? should
+1. I can't imagine any use case for looking up a whole [key, value] pair in
a hash-map.
Actually this is quite useful when you want to do something for each
value and need to know the key as well - for example copy some
key/value pairs to another map
Boris
--
You received this message
Iterating through the pairs is useful. Asking if a given [k, v] is
included is not - you can just ask if (= (assoc k) v) instead.
It'd be nice if (contains-val) returned the key(s) as its true result,
but probably not useful enough to warrant the complexity of dealing
with false keys, explicit
After review, several seq functions from clojure-contrib have been
promoted to clojure [1], [2], [3]. Hopefully the FAQ below will answer
the major questions you may have:
1. Is this a breaking change to Clojure?
No. Rich is super-careful to grow Clojure by expansion, not by
breaking
On 2010 Apr 28, at 4:31 PM, Stuart Halloway wrote:
After review, several seq functions from clojure-contrib have been
promoted to clojure [1], [2], [3]. Hopefully the FAQ below will
answer the major questions you may have:
Cool!
3. Why did some of the fn names change?
...Similarly,
Hi,
On Wed, Apr 28, 2010 at 05:06:21PM -0400, Douglas Philips wrote:
Wait, what? Why should seq-contains? be slower than contains? Isn't
this exactly the kind of thing that protocols are supposed to be
solving? Your nice video showed that very thing, right?
If you have a map or a set looking
On 2010 Apr 28, at 5:14 PM, Meikel Brandmeyer wrote:
If you have a map or a set looking up a key is fast. So contains? is
fast (read O(1) resp. something like O(log32 N)). seq-contains? does
a linear search through a sequence. That is O(N). Protocols cannot
change this.
How is having an
Hi,
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
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
Hi,
On Wed, Apr 28, 2010 at 05:39:37PM -0400, Douglas Philips wrote:
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.
Ah, ok. I misunderstood what you were saying. But I think it
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.
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
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?
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
On 2010 Apr 28, at 6:55 PM, Stuart Halloway wrote:
Specializations are available where there is a clear use case, e.g.
contains?, peek (instead of last), disj, etc.
...
Tying to concrete types is limiting. *Never* having special purpose
fns that know about performance characteristics is also
On 2010 Apr 28, at 6:06 PM, Meikel Brandmeyer wrote:
Ah, ok. I misunderstood what you were saying. But I think it doesn't
change the argumentation. If seq-contains? was fast on maps and sets,
people would abandon contains? because seq-contains? is always
right:
works on seqs, fast on maps and
On Wed, Apr 28, 2010 at 2:39 PM, Douglas Philips d...@mac.com wrote:
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
Wow, and I thought this was a sore subject before, when there was no
seq-contains? and its absence was always a Top 5 FAQ. :-)
I'll wait for Rich to maybe chime in on seq-contains?. Other than seq-
contains? are people liking the new fns? Anybody having issues we
didn't anticipate?
Stu
On Apr 28, 7:17 pm, Douglas Philips d...@mac.com wrote:
On 2010 Apr 28, at 6:55 PM, Stuart Halloway wrote:
Specializations are available where there is a clear use case, e.g.
contains?, peek (instead of last), disj, etc.
...
Tying to concrete types is limiting. *Never* having special
On 2010 Apr 28, at 7:38 PM, Mark Engelberg wrote:
But I think you're not fully appreciating the complexity of the
situation. This is not just about performance, but a question of two
different possible semantics for contains?, which is why it can't
*only* be addressed with a protocol.
...
Hi,
On 29 Apr., 01:38, Mark Engelberg mark.engelb...@gmail.com wrote:
1. Don't include seq-contains? The behavior you want can usually be
achieved by using (some #{item} coll). Disadvantage - if you're
testing to see if the collection contains nil, that won't work.
Not entirely correct.
On 2010 Apr 28, at 11:04 PM, Rich Hickey wrote:
It is an important aspect of Clojure that, in general, performance
guarantees are part of the semantics of functions. In particular,
functions are not supported on data structures where they are not
performant.
Understood. That isn't the
Hi,
On 29 Apr., 01:43, Stuart Halloway stuart.hallo...@gmail.com wrote:
I'll wait for Rich to maybe chime in on seq-contains?. Other than seq-
contains? are people liking the new fns? Anybody having issues we
didn't anticipate?
I was a little bit surprised about map-indexed and
49 matches
Mail list logo
