Amazingly good ideas. Will try it tomorrow. On Fri, Jun 25, 2010 at 8:04 PM, Rich Hickey <richhic...@gmail.com> wrote:
> equiv, the revenge of num > > The latest revision of primitive support is in the equiv branch. It takes > the approach of num, with no auto-promotion, and bigint contagion, and adds > several things to better support contagion. I think contagion is the best > way to continue to support polymorphic numeric code, something I consider > important. > > Contagion has several issues. First and foremost, it means that it it will > be possible for 42 and 42N to be produced in the course of normal > operations, so strict type-specific equality is not a good match. The equiv > branch brings back equivalence-based =, with a slightly tighter notion of =, > supporting only similar categories of numbers, so (= 42 42.0) => false, but > (= 42 42N) => true. == is still available. > > The second problem is the use of numbers (and collections of numbers) as > keys in hash maps and members of hash sets. We already had an issue here, as > there wasn't completely uniform boxing, and there will always be the > possibility of numbers from the outside. The equal branch tried to use > consistent boxing and type-specific =, but it was still open to mismatch > with numbers from outside. The equiv branch extends = to keys and set > members when used from Clojure, i.e. Clojure get and contains will use = > logic, while the Java get and containsKey will use .equals(). I.e. we will > still satisfy the semantics of Java when used through the Java APIs, but > nothing said the Clojure API must match those semantics. When combined with > the new BigInt class (see below), this will allow you to look up (and find!) > the integer 42 with either 42 or 42N. > > The equiv branch also has a new BigInt type. This is strictly necessary for > this scheme, as Java's BigIntegers and Longs can produce different hashCodes > for the same values. In addition to matching hashCode support, the BigInt > class opens the door to better performance when used with numbers > long-or-smaller. These performance enhancements have not yet been made. > > More details have been added to the top here: > > > https://www.assembla.com/wiki/show/b4-TTcvBSr3RAZeJe5aVNr/Enhanced_Primitive_Support > > Code is here: > > http://github.com/richhickey/clojure/commits/equiv > > > Feedback welcome, > > Rich > > -- > 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<clojure%2bunsubscr...@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 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
