On Mar 30, 2009, at 14:51, Rich Hickey wrote: > Well, the community simply has to get together on what they want here, > variously: > > - Clojure sets and maps should implement java.util.Set and Map
Not something I care much about, though I understand those who do. > - Clojure Numbers are the same Integer/Float/Long/Double as Java's, > and math works with Java's Numbers. That looks much more fundamental for Clojure/Java interop, but on the other hand Java's number model is hardly the one of my dreams. > - (= 1 1.0) -> true > > This latter 'feature' is a bear to maintain, as (.equals 1 1.0) -> > false OK, I see now why there is equiv in addition to equals. What a mess... > It would be a lot easier and more consistent if (= 1 1.0) -> false, > but that also implies (= 1 (long 1)) -> false, and people complained > when that was the case. clojure.lang.Numbers should be pretty good > about reducing during math ops, but you still can get Long 1 from a > Java source. Is there a function that converts any Java number to a canonical Clojure representation? With such a function at the Java->Clojure interface, the current state would probably be quite bearable, even though Java numbers could still sneak in and cause unexpected behaviour. > If people were willing to accept type-matching = for numbers, all the > special casing for Numbers and collections would go away. I don't like that idea. The fundamental abstraction for me is "number", not "integer" or "float" which are merely convenient representations for certain subsets of numbers. Konrad. --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
