There's a nice explanation on why Clojure has BigInt in Clojure Programming<http://www.clojurebook.com/> (page 428). Like Mikera wrote, there were two reasons: one was that Java's BigInteger's hashCode is not consistent with Long's hashCode. Secondly Clojure BigInts have been optimized for performance: "while all operations involving BigIntegers must be performed using its (slower) software-based implementations, Clojure optimizes math involving BigInts to use primitive (much faster) operations when possible, as long as the values involved are withing the range of primitive 64-bit longs."
On Monday, 3 February 2014 03:47:41 UTC+2, Mikera wrote: > > It would be a bad idea to wrap up everything in custom types: > > a) It would add a performance overhead. Better to use the Java types > directly - they are very well optimised on the JVM > b) It would make it much harder to use Java libraries and APIs. Java APIs > expect the correct Java type, and wouldn't understand clojure.lang.String > for example > c) There's no real advantage to reinventing the wheel. The Java types are > already pretty good for what they are designed for, e.g. String is fast and > immutable. > d) It would be a lot of extra work. People have better things to do in > this community, I think! > > The clojure.lang.BigInt is a special case - There was probably some good > reason to reimplement java.math.BigInteger (perhaps: performance? getting a > consistent hashcode?) > > Likewise clojure.lang.Ratio doesn't have a good equivalent in the Java > API, so needed to be a new implementation. > > On Monday, 3 February 2014 06:50:01 UTC+8, Mark Gandolfo wrote: >> >> I tried asking this on twitter and wasn't getting my question across in >> 140 characters so I decided to post here. >> I'm curious as to why Clojure as a language hasn't abstracted/hidden all >> of Java's classes and created their own in the Clojure. namespace. >> >> For example >> >> Big Ints are of type and class Clojure.lang.BigInt. >> >> user=> (type 10000N) >> clojure.lang.BigInt >> user=> (class 10000N) >> clojure.lang.BigInt >> >> >> Although a Long is a java.lang.Long both in type and class >> >> user=> (class 1) >> java.lang.Long >> user=> (type 1) >> java.lang.Long >> >> >> Similarly a character is of type java.long.Character >> >> user=> (type \a) >> java.lang.Character >> user=> (class \a) >> java.lang.Character >> >> >> Again with Java strings >> >> user=> (class "string") >> java.lang.String >> user=> (type "string") >> java.lang.String >> >> >> Although a Strings have a few functions in the clojure.strings namespace >> which can be accessed. Why wouldn't clojure.lang.string be the type? And >> somehow inherit/remap all of the java string functions? >> Was this design decision made during the languages conception to clean up >> the clojure namespaces? Or is there another reason that I'm not seeing? >> >> >> -- 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.
