Thanks for the feedback Alex. As far as: > If you wanted to file a jira on anything here, a jira to add a line to the doc string stating that the first duplicate is kept would be the only thing possibly worth doing.
I'll get one logged then. On Saturday, December 31, 2016 at 12:05:16 PM UTC-5, Alex Miller wrote: > > Replying to many things in this thread at once here... > > Re lazy sequences, I think you can take it as implicit and rely on the > input seq order is retained (same as other sequence functions). > > Re duplicates, the current implementation retains the first element, but > as mentioned this is not stated in the doc string (so probably should not > be something you rely upon). > > "Equality" in this case is based upon set contains? checks, which > ultimately use Clojure's "equiv" notion of equality (NOT Java's .equals). > In general for Clojure, equality is based on values and two duplicate > values will be indistinguishable. However, two cases where that might not > be the case are when they have meta (which is not considered in equality) > or if they are arbitrary Java objects (which fall back to .equals behavior). > > If you wanted to file a jira on anything here, a jira to add a line to the > doc string stating that the first duplicate is kept would be the only thing > possibly worth doing. > > Alex > > > On Wednesday, December 28, 2016 at 10:22:53 AM UTC-6, Mike Rodriguez wrote: >> >> The doc for `distinct` is: >> "Returns a lazy sequence of the elements of coll with duplicates removed. >> Returns a stateful transducer when no collection is provided." >> >> (1) In the lazy sequence case, I've thought that maybe it is assuemd >> there is a guarantee that the order of the input seq is preserved. >> However, this isn't stated. Is this an assumption to rely on for >> `distinct` and, more generally, the Clojure seq-based API functions? >> >> (2) In either case, when there are duplicates, there do not seem to be >> any guarantees on which one of the duplicates will be preserved. Should >> this be stated? I'm thinking that maybe this is about Clojure's design >> philosophy being that equal values to not ever need to be distinguished >> between, so the API doesn't explicitly support this concern. However, >> there are times when identity relationships can matter - performance would >> be one that comes to mind. >> - This has some relationship to the Scala question @ >> http://stackoverflow.com/questions/6735568/scala-seqlike-distinct-preserves-order >> >> There have been a few occasions where I relied on (or wanted to rely on) >> (1). I haven't had many cases where (2) matters, but I could see it coming >> up on perhaps rare occasions. >> >> -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
