Re: parameters destructuring sets?
Archive search nth seq hickey: http://groups.google.com/group/clojure/browse_thread/thread/ffa3f56c3bb32bc3/773b23a34e88acab?lnk=gstq=nth+seq+hickey#773b23a34e88acab Stu On Sun, Dec 5, 2010 at 4:14 PM, jweiss jeffrey.m.we...@gmail.com wrote: That's totally different than nth for a set being undefined. It's undefined on purpose. Now, if you are using a sorted-set, then you have a point there, I would expect that nth means something then. But yeah, clojure doesn't let you call nth on it directly, you have to make a seq out of it first. I vote to make nth work on sets and maps, in general, sorted and otherwise, with the well-defined semantics of (identical? (nth set-or-map) (nth (seq (set-or-map. More generally, let nth work on anything that seq works on, by calling seq on its argument when necessary. -- 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
Re: parameters destructuring sets?
On Mon, Dec 6, 2010 at 8:24 AM, Stuart Halloway stuart.hallo...@gmail.com wrote: Archive search nth seq hickey: http://groups.google.com/group/clojure/browse_thread/thread/ffa3f56c3bb32bc3/773b23a34e88acab?lnk=gstq=nth+seq+hickey#773b23a34e88acab Interesting. But that was years ago, Hickey no longer seems to be active on the mailing list, and it certainly seems to me that at the very least sorted sets and sorted maps are sequential. Furthermore, the comment (not made by Hickey) that map order may be unstable is more than a little puzzling in light of the fact that the maps in question are immutable. :) -- 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
Re: parameters destructuring sets?
On Dec 6, 8:36 am, Ken Wesson kwess...@gmail.com wrote: Furthermore, the comment (not made by Hickey) that map order may be unstable is more than a little puzzling in light of the fact that the maps in question are immutable. :) In general, Rich has been careful not to promise things that might limit changes he can make in the future. Sets and maps are unordered. `seq` happens to be deterministic on ArrayMap and HashMap, but there might some day be some other kind of map or set for which `seq` cannot be deterministic. Therefore, Clojure does not promise anything about `seq` on maps, other than that it will return the key-value pairs. -S -- 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
Re: parameters destructuring sets?
On Mon, Dec 6, 2010 at 1:05 PM, Stuart Sierra the.stuart.sie...@gmail.com wrote: On Dec 6, 8:36 am, Ken Wesson kwess...@gmail.com wrote: Furthermore, the comment (not made by Hickey) that map order may be unstable is more than a little puzzling in light of the fact that the maps in question are immutable. :) In general, Rich has been careful not to promise things that might limit changes he can make in the future. Sets and maps are unordered. `seq` happens to be deterministic on ArrayMap and HashMap, but there might some day be some other kind of map or set for which `seq` cannot be deterministic. Therefore, Clojure does not promise anything about `seq` on maps, other than that it will return the key-value pairs. I confess I can't see any obvious reason ever to make seq nondeterministic on an immutable data structure. -- 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
Re: parameters destructuring sets?
On Mon, 6 Dec 2010 16:30:10 -0500 Ken Wesson kwess...@gmail.com wrote: On Mon, Dec 6, 2010 at 1:05 PM, Stuart Sierra the.stuart.sie...@gmail.com wrote: On Dec 6, 8:36 am, Ken Wesson kwess...@gmail.com wrote: Furthermore, the comment (not made by Hickey) that map order may be unstable is more than a little puzzling in light of the fact that the maps in question are immutable. :) In general, Rich has been careful not to promise things that might limit changes he can make in the future. Sets and maps are unordered. `seq` happens to be deterministic on ArrayMap and HashMap, but there might some day be some other kind of map or set for which `seq` cannot be deterministic. Therefore, Clojure does not promise anything about `seq` on maps, other than that it will return the key-value pairs. I confess I can't see any obvious reason ever to make seq nondeterministic on an immutable data structure. I suspect you're applying immutable to everything about the data structure, whereas it can also be applied the value without including the implementation. I can see wanting to change the implementation in ways that don't change the value - triggered by something like wanting to share parts of the value with another structure, or a garbage collection, or ... - which could easily change the results of calling seq on the structure. Not that I know that anything in clojure does that, just that I can see conditions where you might want to. mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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
Re: parameters destructuring sets?
On Mon, Dec 6, 2010 at 4:44 PM, Mike Meyer
mwm-keyword-googlegroups.620...@mired.org wrote:
On Mon, 6 Dec 2010 16:30:10 -0500
Ken Wesson kwess...@gmail.com wrote:
On Mon, Dec 6, 2010 at 1:05 PM, Stuart Sierra
the.stuart.sie...@gmail.com wrote:
On Dec 6, 8:36 am, Ken Wesson kwess...@gmail.com wrote:
Furthermore, the comment (not made by Hickey) that map order may be
unstable is more than a little puzzling in light of the fact that the
maps in question are immutable. :)
In general, Rich has been careful not to promise things that might
limit changes he can make in the future. Sets and maps are unordered.
`seq` happens to be deterministic on ArrayMap and HashMap, but there
might some day be some other kind of map or set for which `seq` cannot
be deterministic. Therefore, Clojure does not promise anything about
`seq` on maps, other than that it will return the key-value pairs.
I confess I can't see any obvious reason ever to make seq
nondeterministic on an immutable data structure.
I suspect you're applying immutable to everything about the data
structure, whereas it can also be applied the value without including
the implementation. I can see wanting to change the implementation in
ways that don't change the value - triggered by something like wanting
to share parts of the value with another structure, or a garbage
collection, or ... - which could easily change the results of calling
seq on the structure.
Perhaps. But under those circumstances seq itself has the same problem
you're using to excuse not supporting nth, yet seq is supported. And
so is (nth (seq x)) on these things; if the implementation changed its
innards while you were walking the seq (even with map! Nevermind using
nth) this could trip up. You might have a set #{1 2 3 4 5 6} and seq
would produce (1 3 4 5 2 6) and then someone makes another set from it
with disj and the structure rearranges, so seq would now produce (1 5
6 2 4 3). Meanwhile, another thread has produced a seq and is
traversing it at the time and gets (1 3 4 2 4 3). Oops.
If that kind of internal rearrangement is to be done, seq will have to
copy the structure's contents (by realizing the seq promptly; so there
goes laziness) in order to avoid that kind of error. And once you have
that, you will want to create AND CACHE the (immutable!) structure's
seq-representation when it's first needed. And you can do so when nth
is called, as well as seq. And then due to the caching both nth and
seq will obey (if (identical? s1 s2) (identical? (f s1) (f s2))) when
substituted for f.
Even then, I'd expect internal rearrangement to be a thread-safety
nightmare; in all likelihood a) rearranging operations, and b)
operations like realizing the seq that will be b0rked by concurrent
rearrangements, will require locking the structure. Locking is
supposed to be kept to a minimum as one of Clojure's design goals,
IIRC.
This gets worse when you note that seq realization can cause the
execution of user-supplied code (e.g. the body of a lazy-seq macro)
during realization. If user-supplied code can end up executing with
user-invisible monitors locked, and can in turn cause more monitors to
be locked (say, by disjing a set thus causing one of your hypothetical
internal rearrangements), then it can cause deadlocks that would be
fiendishly difficult to track down and fix. And deadlock avoidance is
*emphatically* one of Clojure's design goals.
--
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
Re: parameters destructuring sets?
On Mon, 6 Dec 2010 17:07:15 -0500
Ken Wesson kwess...@gmail.com wrote:
On Mon, Dec 6, 2010 at 4:44 PM, Mike Meyer
mwm-keyword-googlegroups.620...@mired.org wrote:
On Mon, 6 Dec 2010 16:30:10 -0500
Ken Wesson kwess...@gmail.com wrote:
On Mon, Dec 6, 2010 at 1:05 PM, Stuart Sierra
the.stuart.sie...@gmail.com wrote:
On Dec 6, 8:36 am, Ken Wesson kwess...@gmail.com wrote:
Furthermore, the comment (not made by Hickey) that map order may be
unstable is more than a little puzzling in light of the fact that the
maps in question are immutable. :)
In general, Rich has been careful not to promise things that might
limit changes he can make in the future. Sets and maps are unordered.
`seq` happens to be deterministic on ArrayMap and HashMap, but there
might some day be some other kind of map or set for which `seq` cannot
be deterministic. Therefore, Clojure does not promise anything about
`seq` on maps, other than that it will return the key-value pairs.
I confess I can't see any obvious reason ever to make seq
nondeterministic on an immutable data structure.
I suspect you're applying immutable to everything about the data
structure, whereas it can also be applied the value without including
the implementation. I can see wanting to change the implementation in
ways that don't change the value - triggered by something like wanting
to share parts of the value with another structure, or a garbage
collection, or ... - which could easily change the results of calling
seq on the structure.
Perhaps. But under those circumstances seq itself has the same problem
you're using to excuse not supporting nth, yet seq is supported.
I had some trouble figuring out what you're saying here, so let me
know if I got this wrong: I'm providing reasons for seq to not have a
guarantee of determinism when called on some structures, and that
non-determinism is the justification for nth not being supported, so
why is seq supported?
A non-deterministic nth has no value - you might as well just use
first (and in fact, you can). A non-deterministic seq, on the other
hand, *does* have a value: it provides representation of the value for
which nth (and friends) have a deterministic value.
Having nth call seq on structures for which seq is non-deterministic
would slow down nth, and possibly hide buggy code. Forcing the call to
seq be explicit means there's a chance they'll notice the
non-deterministic result, and fix the bug.
And so is (nth (seq x)) on these things; if the implementation
changed its innards while you were walking the seq (even with map!
Nevermind using nth) this could trip up. You might have a set #{1 2
3 4 5 6} and seq would produce (1 3 4 5 2 6) and then someone makes
another set from it with disj and the structure rearranges, so seq
would now produce (1 5 6 2 4 3). Meanwhile, another thread has
produced a seq and is traversing it at the time and gets (1 3 4 2 4
3). Oops.
There are a number of ways to avoid this bug. You found at least one
of them here:
If that kind of internal rearrangement is to be done, seq will have to
copy the structure's contents (by realizing the seq promptly; so there
goes laziness) in order to avoid that kind of error. And once you have
that, you will want to create AND CACHE the (immutable!) structure's
seq-representation when it's first needed. And you can do so when nth
is called, as well as seq. And then due to the caching both nth and
seq will obey (if (identical? s1 s2) (identical? (f s1) (f s2))) when
substituted for f.
Even then, I'd expect internal rearrangement to be a thread-safety
nightmare; in all likelihood a) rearranging operations, and b)
operations like realizing the seq that will be b0rked by concurrent
rearrangements, will require locking the structure. Locking is
supposed to be kept to a minimum as one of Clojure's design goals,
IIRC.
This gets worse when you note that seq realization can cause the
execution of user-supplied code (e.g. the body of a lazy-seq macro)
during realization. If user-supplied code can end up executing with
user-invisible monitors locked, and can in turn cause more monitors to
be locked (say, by disjing a set thus causing one of your hypothetical
internal rearrangements), then it can cause deadlocks that would be
fiendishly difficult to track down and fix. And deadlock avoidance is
*emphatically* one of Clojure's design goals.
All true. As far as I'm concerned, it's also all irrelevant. Just
because doing a thing is hard in all known examples doesn't mean you
want to give up the right to do it should you decide you need to.
mike
--
Mike Meyer m...@mired.org http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O ascii ribbon campaign - stop html mail - www.asciiribbon.org
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post
Re: parameters destructuring sets?
On Dec 6, 2010, at 4:07 PM, Ken Wesson wrote:
Perhaps. But under those circumstances seq itself has the same problem
you're using to excuse not supporting nth, yet seq is supported. And
so is (nth (seq x)) on these things; if the implementation changed its
innards while you were walking the seq (even with map! Nevermind using
nth) this could trip up. You might have a set #{1 2 3 4 5 6} and seq
would produce (1 3 4 5 2 6) and then someone makes another set from it
with disj and the structure rearranges, so seq would now produce (1 5
6 2 4 3). Meanwhile, another thread has produced a seq and is
traversing it at the time and gets (1 3 4 2 4 3). Oops.
Why is this a problem? Why would you rely on the order in which (seq) hands you
items from an unordered collection in the first place? If you care about order,
use an ordered collection. Besides that, it's really uncommon in my experience
to traverse the same collection twice while caring about the ordering.
The point of requiring a manual call to (seq) is to make it explicit that you
are viewing this thing as a seq, with all that implies. To quote Rich from the
previously-referenced thread:
If in some situation it makes sense to treat a map as sequential (it might
make some sense with array maps or sorted maps), just use (seq m), which will
serve as an indicator of that special point of view.
Given the reasoning above, I'd argue that the fact that (first), (rest), and
(next) work on unordered collections is actually a bug.
--
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
Re: parameters destructuring sets?
On Mon, Dec 6, 2010 at 5:43 PM, Michael Gardner gardne...@gmail.com wrote:
On Dec 6, 2010, at 4:07 PM, Ken Wesson wrote:
Perhaps. But under those circumstances seq itself has the same problem
you're using to excuse not supporting nth, yet seq is supported. And
so is (nth (seq x)) on these things; if the implementation changed its
innards while you were walking the seq (even with map! Nevermind using
nth) this could trip up. You might have a set #{1 2 3 4 5 6} and seq
would produce (1 3 4 5 2 6) and then someone makes another set from it
with disj and the structure rearranges, so seq would now produce (1 5
6 2 4 3). Meanwhile, another thread has produced a seq and is
traversing it at the time and gets (1 3 4 2 4 3). Oops.
Why is this a problem? Why would you rely on the order in which (seq) hands
you items from an unordered collection in the first place?
Who was relying on the order? If you merely relied on seeing 5 or 6,
or on not seeing 3 or 4 twice, you were screwed.
The point was that you can't even rely on seeing all of the elements,
once each, in *some* order, unless the seq is a copy instead of a view
backed by the other data structure. And if it's a copy, it is
expensive to produce. And if it is expensive to produce, it can be
cached once produced. And if it can be cached once produced, nth can
give consistent results by consulting the cached seq.
Or, put another way: *either* there is a seq version of the collection
that has a stable, if effectively random, order (and nth can be made
to work) *or* simply walking (seq the-coll) will potentially produce
inconsistent behavior, such as walking (seq a-set) and seeing
duplicates, or walking almost anything and missing an element that was
in there.
The latter is clearly undesirable behavior when calling seq on a
nominally-immutable collection, so I do hope any collections whose
innards do rearrange have seq produce a seq-copy rather than a
seq-view. But if the collection either does not rearrange *or*
produces a seq-copy when seq'd, then nth can be made to work on it in
a consistent way.
And, of course, none of this affects the obviously ordered *sorted*
set or the obviously ordered *sorted* map, which was the case
originally under discussion.
--
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
Re: parameters destructuring sets?
sorry to jump in this weird conversation, but it seems to me that you are on
parallel discussion without acknowleding it.
To me, the only thing which makes sense is that saying that seq promises no
deterministic ordering on sets and maps is not about calling seq on the same
java instance of a set or map twice.
It's just about acknowledging that, for example :
(not= (seq m) (rest (seq (assoc m :key :value ;; silly example
or that two sets or maps appearing to be = , but not constructed via the
same assoc(iations) in the same order will not provide items in the same
order when seq is called on them:
user= (def m1 {:k1 :v1 :k2 :v2})
#'user/m1
user= (def m2 {:k2 :v2 :k1 :v1})
#'user/m2
user= (into () (seq m1))
([:k2 :v2] [:k1 :v1])
user= (into () (seq m2))
([:k1 :v1] [:k2 :v2])
user= (= m1 m2)
true
user=
2010/12/7 Ken Wesson kwess...@gmail.com
On Mon, Dec 6, 2010 at 5:43 PM, Michael Gardner gardne...@gmail.com
wrote:
On Dec 6, 2010, at 4:07 PM, Ken Wesson wrote:
Perhaps. But under those circumstances seq itself has the same problem
you're using to excuse not supporting nth, yet seq is supported. And
so is (nth (seq x)) on these things; if the implementation changed its
innards while you were walking the seq (even with map! Nevermind using
nth) this could trip up. You might have a set #{1 2 3 4 5 6} and seq
would produce (1 3 4 5 2 6) and then someone makes another set from it
with disj and the structure rearranges, so seq would now produce (1 5
6 2 4 3). Meanwhile, another thread has produced a seq and is
traversing it at the time and gets (1 3 4 2 4 3). Oops.
Why is this a problem? Why would you rely on the order in which (seq)
hands you items from an unordered collection in the first place?
Who was relying on the order? If you merely relied on seeing 5 or 6,
or on not seeing 3 or 4 twice, you were screwed.
The point was that you can't even rely on seeing all of the elements,
once each, in *some* order, unless the seq is a copy instead of a view
backed by the other data structure. And if it's a copy, it is
expensive to produce. And if it is expensive to produce, it can be
cached once produced. And if it can be cached once produced, nth can
give consistent results by consulting the cached seq.
Or, put another way: *either* there is a seq version of the collection
that has a stable, if effectively random, order (and nth can be made
to work) *or* simply walking (seq the-coll) will potentially produce
inconsistent behavior, such as walking (seq a-set) and seeing
duplicates, or walking almost anything and missing an element that was
in there.
The latter is clearly undesirable behavior when calling seq on a
nominally-immutable collection, so I do hope any collections whose
innards do rearrange have seq produce a seq-copy rather than a
seq-view. But if the collection either does not rearrange *or*
produces a seq-copy when seq'd, then nth can be made to work on it in
a consistent way.
And, of course, none of this affects the obviously ordered *sorted*
set or the obviously ordered *sorted* map, which was the case
originally under discussion.
--
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.comclojure%2bunsubscr...@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
Re: parameters destructuring sets?
On Dec 6, 2010, at 5:35 PM, Ken Wesson wrote: Who was relying on the order? If you merely relied on seeing 5 or 6, or on not seeing 3 or 4 twice, you were screwed. Ah, I misunderstood what you wrote. Obviously (seq) should hand you each item in the collection exactly once, but that's at a weaker guarantee than that different calls to (seq) on the same collection should always hand them to you in the same order. The point was that you can't even rely on seeing all of the elements, once each, in *some* order, unless the seq is a copy instead of a view backed by the other data structure. I don't see how this follows. It seems like you're making some unstated assumptions about how (seq) gets items from the underlying collection. And if it's a copy, it is expensive to produce. And if it is expensive to produce, it can be cached once produced. And if it can be cached once produced, nth can give consistent results by consulting the cached seq. It's not just about (nth) giving consistent results. It's also about forcing the programmer to make his intentions explicit, per Rich's quote. -- 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
Re: parameters destructuring sets?
On Mon, Dec 6, 2010 at 7:10 PM, Michael Gardner gardne...@gmail.com wrote:
On Dec 6, 2010, at 5:35 PM, Ken Wesson wrote:
Who was relying on the order? If you merely relied on seeing 5 or 6,
or on not seeing 3 or 4 twice, you were screwed.
Ah, I misunderstood what you wrote. Obviously (seq) should hand you each item
in the collection exactly once, but that's at a weaker guarantee than that
different calls to (seq) on the same collection should always hand them to
you in the same order.
The point was that you can't even rely on seeing all of the elements,
once each, in *some* order, unless the seq is a copy instead of a view
backed by the other data structure.
I don't see how this follows. It seems like you're making some unstated
assumptions about how (seq) gets items from the underlying collection.
I'll try this one more time. You suggested the innards, and with them
the seq order of the elements, might get rearranged. If (seq c)
produces a lazy seq that is backed by some kind of iterator traversing
some data structure underlying c and such a rearrangement happens
during said traversal, then there are two branching possibilities.
1. The iterator just keeps traversing even though it's now on
quicksand. (Or worse, it stops with a ConcurrentModificationException
or something.) In that event, the seq contract is broken. At best
you'll get traversals like (1 3 4 2 4 3) sometimes from traversing
things like #{1 2 3 4 5 6}; more likely you'll get things like (1 3 4
2) that simply stop short and omit items; at worst, exception throws.
2. There is some way in which the seq holds onto a particular
ordering of the elements, even through rearrangements. The seq may be
non-lazy, created as a PersistentList of the elements when seq was
called; or the structure may include a (stable!) linking system for
traversing the elements (ala java.util.LinkedHashMap), or something.
In case #2, seq meets its contract, but nth can also be made to work
easily enough; in the linking-system case nth naturally works
stably, whereas in the non-lazy case the seq version once created can
be cached, both making repeated calls to seq cheaper and making nth
work in a consistent way on that instance.
In case #1, on the other hand, though nth can't be made to work *seq
can't be made to work either* even though it is supported -- it's
supported, and yet *it'll break and needs to be fixed* if the
structure is rewritten to rearrange its innards. And fixing it will
necessarily also fix nth.
And if it's a copy, it is
expensive to produce. And if it is expensive to produce, it can be
cached once produced. And if it can be cached once produced, nth can
give consistent results by consulting the cached seq.
It's not just about (nth) giving consistent results. It's also about forcing
the programmer to make his intentions explicit, per Rich's quote.
We may just have to agree to disagree about that. It seems to me that
calling nth, or first, or seq, or anything like that makes the
programmer's intentions explicit, as those are all clearly treating
the structure as a sequence. It's calling (foo coll) where foo calls
(nth (seq coll)) or somesuch under the hood that doesn't make the
programmer's intentions (as) explicit; they're calling some function
on, say, a map and it may not be especially obvious that that function
treats the map (and anything else passed to it) as a sequence.
Anyway, you can't legislate code clarity at the language level. They
tried that with Java and look where it got them. Annotations,
generics, and checked exceptions, oh my!
--
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
Re: parameters destructuring sets?
On Dec 6, 2010, at 9:02 PM, Ken Wesson wrote: I'll try this one more time. You suggested the innards, and with them the seq order of the elements, might get rearranged. I suggested no such thing; perhaps you are confusing me with Mike Meyer? I referred more generally to the possibility of two different calls to (seq) on the same collection returning the items in different orders. This might happen if e.g. the underlying collection picks a starting point for the iterators it returns non-deterministically. I'm not saying this is likely to be done in practice, mind you, just that there are conceivable cases where an immutable collection would not want to provide that kind of ordering guarantee. It's not just about (nth) giving consistent results. It's also about forcing the programmer to make his intentions explicit, per Rich's quote. We may just have to agree to disagree about that. It seems to me that calling nth, or first, or seq, or anything like that makes the programmer's intentions explicit, as those are all clearly treating the structure as a sequence. It's calling (foo coll) where foo calls (nth (seq coll)) or somesuch under the hood that doesn't make the programmer's intentions (as) explicit; they're calling some function on, say, a map and it may not be especially obvious that that function treats the map (and anything else passed to it) as a sequence. Anyway, you can't legislate code clarity at the language level. They tried that with Java and look where it got them. Annotations, generics, and checked exceptions, oh my! I don't actually have a strong opinion one way or the other on this, though I can see how it would appear otherwise from what I wrote. I was just giving what I understood to be one of the official reasons for the decision. -- 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
Re: parameters destructuring sets?
On Mon, Dec 6, 2010 at 10:45 PM, Michael Gardner gardne...@gmail.com wrote: On Dec 6, 2010, at 9:02 PM, Ken Wesson wrote: I'll try this one more time. You suggested the innards, and with them the seq order of the elements, might get rearranged. I suggested no such thing; perhaps you are confusing me with Mike Meyer? Actually, the you in my post was a generic you, meaning whoever's arguing against this. I referred more generally to the possibility of two different calls to (seq) on the same collection returning the items in different orders. The only plausible reason I can think of for this to happen IS if the innards get rearranged behind the scenes to, say, better support structure-sharing. This is why I considered yours and Meyer's positions to be equivalent enough to address them both with a single argument containing a generic you. -- 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
parameters destructuring sets?
Hello all I have following question to Rich and other core developers of Clojure - why parameters destructuring requires presence of 'nth' implementation for destructuring of sequences? The [[x more]] idiom is very popular and could make code more concise, but it doesn't work for sets and some other collections, like java's HashMap, etc. If this is performance-related problem - may we could have 2 different implementations, depending on sequence type? I found this when trying to use string/join function for set, and fixed this in http://dev.clojure.org/jira/browse/CLJ-687 - so we can use join for any sequence -- With best wishes, Alex Ott, MBA http://alexott.blogspot.com/http://alexott.net/ http://alexott-ru.blogspot.com/ Skype: alex.ott -- 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
Re: parameters destructuring sets?
Re jweiss at Sun, 5 Dec 2010 10:29:41 -0800 (PST) wrote: j I'm no expert on this, but i'll take a crack at it. j I think it's because sets don't (necessarily) impose any order, so j there's no concept of first or nth. So destructuring would j essentially be assigning a random item to x, or for join, joining them j in random order. Sometimes, order doesn't matter, for example, I want to print data from set (or any collection that is transformable into sequence), using some separator between elements... For some operations we can't also predict order, for example, conj behaves differently for lists and vectors -- With best wishes, Alex Ott, MBA http://alexott.blogspot.com/http://alexott.net/ http://alexott-ru.blogspot.com/ Skype: alex.ott -- 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
Re: parameters destructuring sets?
On Dec 5, 2:10 pm, Alex Ott alex...@gmail.com wrote:
Re
jweiss at Sun, 5 Dec 2010 10:29:41 -0800 (PST) wrote:
j I'm no expert on this, but i'll take a crack at it.
j I think it's because sets don't (necessarily) impose any order, so
j there's no concept of first or nth. So destructuring would
j essentially be assigning a random item to x, or for join, joining them
j in random order.
Sometimes, order doesn't matter, for example, I want to print data from set
(or any collection that is transformable into sequence), using some
separator between elements...
For some operations we can't also predict order, for example, conj behaves
differently for lists and vectors
--
With best wishes, Alex Ott, MBAhttp://alexott.blogspot.com/
http://alexott.net/http://alexott-ru.blogspot.com/
Skype: alex.ott
If you wanted to, for example, print a set with separators in between,
would you need to use destructuring?
I'd just do (apply str (interpose , #{:a :b :c})
- :a,:b,:c
I don't think conj adding to the front for lists and the end for
vectors is unpredictable at all. I know that
(conj '(1 2) 3))
- (3 1 2)
and
(conj [1 2] 3)
- [1 2 3]
before I even type it on a REPL. That's totally different than nth
for a set being undefined. It's undefined on purpose.
Now, if you are using a sorted-set, then you have a point there, I
would expect that nth means something then. But yeah, clojure doesn't
let you call nth on it directly, you have to make a seq out of it
first. Not sure what the performance implication is there, but it's
not much effort to write:
(nth (sequence (sorted-set 1 3 2)) 2)
- 3
I will let people who are more knowledgeable comment on why there's no
nth on a sorted-set.
--
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
Re: parameters destructuring sets?
On Sun, Dec 5, 2010 at 1:29 PM, jweiss jeffrey.m.we...@gmail.com wrote: I'm no expert on this, but i'll take a crack at it. I think it's because sets don't (necessarily) impose any order, so there's no concept of first or nth. So destructuring would essentially be assigning a random item to x, or for join, joining them in random order. I'm curious what the use case is here. One obvious one would be any commutative, associative operation. (apply + some-set) won't care about the order of the arguments, for instance. -- 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
Re: parameters destructuring sets?
On Sun, Dec 5, 2010 at 4:14 PM, jweiss jeffrey.m.we...@gmail.com wrote: That's totally different than nth for a set being undefined. It's undefined on purpose. Now, if you are using a sorted-set, then you have a point there, I would expect that nth means something then. But yeah, clojure doesn't let you call nth on it directly, you have to make a seq out of it first. I vote to make nth work on sets and maps, in general, sorted and otherwise, with the well-defined semantics of (identical? (nth set-or-map) (nth (seq (set-or-map. More generally, let nth work on anything that seq works on, by calling seq on its argument when necessary. -- 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
Re: parameters destructuring sets?
+1 to what Ken said Sunil On Mon, Dec 6, 2010 at 4:04 AM, Ken Wesson kwess...@gmail.com wrote: On Sun, Dec 5, 2010 at 4:14 PM, jweiss jeffrey.m.we...@gmail.com wrote: That's totally different than nth for a set being undefined. It's undefined on purpose. Now, if you are using a sorted-set, then you have a point there, I would expect that nth means something then. But yeah, clojure doesn't let you call nth on it directly, you have to make a seq out of it first. I vote to make nth work on sets and maps, in general, sorted and otherwise, with the well-defined semantics of (identical? (nth set-or-map) (nth (seq (set-or-map. More generally, let nth work on anything that seq works on, by calling seq on its argument when necessary. -- 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.comclojure%2bunsubscr...@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
Re: parameters destructuring sets?
If sets don't have a set ordering, then why should seq on a set always return the same order for the same set? If seq doesn't always return the a seq with the same order, then (nth set 5) might be different than a future call to (nth set 5), because the underlying sequence returned by the set might change. If seq on a set always returns a seq with the same order, then that may limit the future efficiency of sets. --Robert McIntyre On Sun, Dec 5, 2010 at 8:08 PM, Sunil S Nandihalli sunil.nandiha...@gmail.com wrote: +1 to what Ken said Sunil On Mon, Dec 6, 2010 at 4:04 AM, Ken Wesson kwess...@gmail.com wrote: On Sun, Dec 5, 2010 at 4:14 PM, jweiss jeffrey.m.we...@gmail.com wrote: That's totally different than nth for a set being undefined. It's undefined on purpose. Now, if you are using a sorted-set, then you have a point there, I would expect that nth means something then. But yeah, clojure doesn't let you call nth on it directly, you have to make a seq out of it first. I vote to make nth work on sets and maps, in general, sorted and otherwise, with the well-defined semantics of (identical? (nth set-or-map) (nth (seq (set-or-map. More generally, let nth work on anything that seq works on, by calling seq on its argument when necessary. -- 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 -- 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
Re: parameters destructuring sets?
On Sun, Dec 5, 2010 at 8:26 PM, Robert McIntyre r...@mit.edu wrote: If sets don't have a set ordering, then why should seq on a set always return the same order for the same set? If seq doesn't always return the a seq with the same order, then (nth set 5) might be different than a future call to (nth set 5), because the underlying sequence returned by the set might change. If seq on a set always returns a seq with the same order, then that may limit the future efficiency of sets. I'm fairly sure seq on a set is deterministic rather than random, and since the set is immutable ... I'd say that (identical? s1 s2) can guarantee (identical? (nth s1 n) (nth s2 n)) for all n without unduly constraining set implementation. Whether (= s1 s2) can still guarantee that is a bit more complicated. Hashset order is determined by the order of the hash codes of the elements. If there's a hash collision I suppose order of the colliding elements might be determined by what got conjed in first, and then (= s1 s2) would fail to guarantee that. One way around it that's performance cheap but somewhat memory expensive is to include next links in set and map entries, making them double as lists. This would impair structure sharing, however. Another is to make hash buckets keep items in a deterministic order -- somehow. None of this makes nth poorly defined for the specific case of sorted sets and maps. Nor does it change the fact that if the above is a problem, then (= s1 s2) doesn't guarantee (= (seq s1) (seq s2)), which might itself be regarded as a problem and, if so, is one that *already exists*. -- 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
