One thing I was surprised by in my investigation was the lengths that some people are willing to go to in order to avoid such things.
Some people seem to *really* want the property "x is equal to y" to imply "f(x) is equal to f(y)" for all functions, without exception, and consider it a bug if a single function violates that property. I'm personally on the side of violating it if there is no good way to keep it true for a particular function, preferably with documentation if you are aware that you are not preserving it. Andy On Tue, Apr 21, 2015 at 8:32 PM, Dave Sann <daves...@gmail.com> wrote: > Just to expand on this slightly - seq applied to a set must introduce an > order that is not present in the set. This order in principle comes from > nowhere in the data. But it does in practice come from some arbitrary > decisions in the implementation. Maybe this was andy's point. > > > On Wednesday, 22 April 2015 13:18:43 UTC+10, Dave Sann wrote: >> >> Agree it's an interesting writeup. >> >> I think that the behaviour of seq should be entirely expected though. >> Sets have no ordering (logically) so turning them into an ordered sequence >> should be considered to be an entirely arbitrary operation (unless specific >> guarantees are provided). The fact that the implementations sometimes >> maintain an order should not be used or relied upon at all. >> >> a seq of a set is not itself a set and therefore is not subject to the >> same referential transparency rules as a set. >> >> Dave >> >> On Wednesday, 22 April 2015 12:39:42 UTC+10, Mike Rodriguez wrote: >>> >>> Thanks for sharing this. I found the write-up to be very informative >>> and to have good background sources. >>> >>> I certainly never thought about this sneaky behavior concerning `seq` >>> and hash sets before now. I'll have to look out for that one! >>> >>> On Tuesday, April 21, 2015 at 8:13:48 PM UTC-5, Andy Fingerhut wrote: >>>> >>>> I had come across the issue of Clojure hash sets that contain the same >>>> set of elements returning their elements in different orders from each >>>> other, depending upon which order they were added to the set (only if they >>>> have equal values for (hash x)). >>>> >>>> This and other questions on referential transparency on the Clojure >>>> group got me thinking on my commutes about it some more, and I dug into it >>>> way more than I expected to, and wrote up an article on it. If you think >>>> such a topic would interest you, you can read more about it here: >>>> >>>> >>>> https://github.com/jafingerhut/thalia/blob/master/doc/other-topics/referential-transparency.md >>>> >>>> Guaranteed at least 99% epiphany free >>>> >>>> Andy >>>> >>>> -- > 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. > -- 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.
