To add just one more thing to this: Referential transparency is clearly valuable, but it's not the *only* valuable property a function or system might have. There are always tradeoffs to be made. Clojure has made different tradeoffs than you expected, or would yourself have made, but that doesn't /a priori/ mean they're wrong.
- John John Mastro <john.b.mas...@gmail.com> wrote: > Hi Andy, > > Andy C <andy.coolw...@gmail.com> wrote: >> >> >>> user> (= s1 s2) >>> true >>> user> (= (seq s1) (seq s2)) >>> false >> >> >> Thx. If a=b then f(a) must = f(b). Something is broken here. > > If a seq is a sequential view of a thing, and a set is an unordered thing, > then > it does not seem shocking to me that multiple sequential views of a given set, > with different orderings, are possible. > > This may not be the only way to do things; and it may not be the way other > languages do it; and it may not match your preference. But I think it's > clearly > wrong to say that it's internally inconsistent or "broken". > > It's perhaps hard to say this without sounding condescending, but rather than > seeking to identify all the ways in which Clojure isn't Haskell, it might be > more useful to pursue an understanding of Clojure (including its > definitely-not-nonexistent flaws!) on its own terms. > > - John -- 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/groups/opt_out.
