Yeah, adding a test for undocumented behavior seems somewhat reasonable. I do wish the docs would be a bit clearer on these aspects of the contract. Without that it just doesn't seem that there is any real commitment to the Clojure implementation to not change later.
I understand the general idea of "it is the most natural way to implement it". However, that is shaky grounds to rely on. It also makes me question if I've really thought it through to know "there isn't any other way to do it". In the case of `distinct` I can be fairly sure it won't reorder them. Also, it still isn't clear if it keeps the first or later duplicates or not. That was the (2) part of the question. I'm just guessing there the answer may just be "equal values are equal and you should never care which one you get out". There are times to care though, but then perhaps just don't use `distinct` or be sure to have a test on it. :P I asked this question mostly out of curiosity and to see what others thought. Also, to bring up the issue of if the docs are sufficient. On Wednesday, December 28, 2016 at 3:38:03 PM UTC-6, tbc++ wrote: > > This is one of those odd questions where the answer of what "could" happen > and what "will most likely happen" are completely different. There is no > reason why `distinct` should reorder or which item will be preserved. > However there's really only one logical way to implement this (the way it's > currently implemented) and in that case the answer would be "the first > duplicate is used", and "items are not reordered". > > So all that to say, there's nothing in the docs that specify this is the > way it has to be, but it is the way it is now, is most likely not going to > change. So if you're really concerned about it, I'd say write a test around > distinct and wait for it to break someday if Clojure changes the undefined > behavior. > > On Wed, Dec 28, 2016 at 9:55 AM, Michael Blume <blume...@gmail.com > <javascript:>> wrote: > >> Also, I'm assuming distinct uses .equals semantics which might be worth >> calling out in the doc >> >> On Wed, Dec 28, 2016, 11:22 AM Mike Rodriguez <mjr...@gmail.com >> <javascript:>> 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 clo...@googlegroups.com >>> <javascript:> >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+u...@googlegroups.com <javascript:> >>> 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+u...@googlegroups.com <javascript:>. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com >> <javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> 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+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > “One of the main causes of the fall of the Roman Empire was that–lacking > zero–they had no way to indicate successful termination of their C > programs.” > (Robert Firth) > -- 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.
