Re: parameters destructuring & sets?
On Mon, Dec 6, 2010 at 10:45 PM, Michael Gardner 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
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 7:10 PM, Michael Gardner 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 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?
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
> On Mon, Dec 6, 2010 at 5:43 PM, Michael Gardner
> 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
>
--
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 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?
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, 6 Dec 2010 17:07:15 -0500
Ken Wesson wrote:
> On Mon, Dec 6, 2010 at 4:44 PM, Mike Meyer
> wrote:
> > On Mon, 6 Dec 2010 16:30:10 -0500
> > Ken Wesson wrote:
> >
> >> On Mon, Dec 6, 2010 at 1:05 PM, Stuart Sierra
> >> wrote:
> >> > On Dec 6, 8:36 am, Ken Wesson 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.
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 c
Re: parameters destructuring & sets?
On Mon, Dec 6, 2010 at 4:44 PM, Mike Meyer
wrote:
> On Mon, 6 Dec 2010 16:30:10 -0500
> Ken Wesson wrote:
>
>> On Mon, Dec 6, 2010 at 1:05 PM, Stuart Sierra
>> wrote:
>> > On Dec 6, 8:36 am, Ken Wesson 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 16:30:10 -0500 Ken Wesson wrote: > On Mon, Dec 6, 2010 at 1:05 PM, Stuart Sierra > wrote: > > On Dec 6, 8:36 am, Ken Wesson 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. 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 1:05 PM, Stuart Sierra wrote: > On Dec 6, 8:36 am, Ken Wesson 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 Dec 6, 8:36 am, Ken Wesson 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 8:24 AM, Stuart Halloway wrote: > Archive search "nth seq hickey": > > http://groups.google.com/group/clojure/browse_thread/thread/ffa3f56c3bb32bc3/773b23a34e88acab?lnk=gst&q=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?
Archive search "nth seq hickey": http://groups.google.com/group/clojure/browse_thread/thread/ffa3f56c3bb32bc3/773b23a34e88acab?lnk=gst&q=nth+seq+hickey#773b23a34e88acab Stu > On Sun, Dec 5, 2010 at 4:14 PM, jweiss 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 Sun, Dec 5, 2010 at 8:26 PM, Robert McIntyre 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
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 wrote: > +1 to what Ken said > Sunil > > On Mon, Dec 6, 2010 at 4:04 AM, Ken Wesson wrote: >> >> On Sun, Dec 5, 2010 at 4:14 PM, jweiss 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?
+1 to what Ken said Sunil On Mon, Dec 6, 2010 at 4:04 AM, Ken Wesson wrote: > On Sun, Dec 5, 2010 at 4:14 PM, jweiss 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 Sun, Dec 5, 2010 at 4:14 PM, jweiss 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?
On Sun, Dec 5, 2010 at 1:29 PM, jweiss 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 Dec 5, 2:10 pm, Alex Ott 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?
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?
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. Jeff On Dec 5, 12:39 pm, Alex Ott wrote: > 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 inhttp://dev.clojure.org/jira/browse/CLJ-687- so we can use join for > any sequence > > -- > With best wishes, Alex Ott, MBAhttp://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
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
