> Everyone has to realize the math you are advocating for the default, on > non-tagged architectures like the JVM and CLR, *must* do an allocation on > every +/-/* etc operation. And such ops are littered throughout non-numeric > data structure code, for indexes, offsets, bounds etc. Allocating on every > math op in something like the persistent vector would make it completely > unusably slow. >
I think my understanding of the trade-offs is stuck on this question: If the auto-promoting ops were chosen as the default, why couldn't Clojure-in-Clojure use the fast ops rather than the default ops? Couldn't the implementation of PersistentVector use primitives on the inside without anyone on the outside ever knowing? (I guess the answer is no, but I'm not understanding why. Sorry for being behind the curve.) A second question: I see why the uber-loop requires ops that return primitives, but what would be the problem with simply having a loop and a loop'? Is the problem that then we go down the road of bifurcating all functions into fast and slow? I like easy photosynthesis and I'm all for raising my game, but I'd like a better understanding of why I can't have my gazelle in this case and eat it too. -- 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
