On 18/06/2010, at 12:30 PM, Rich Hickey wrote: > You raise several points, I'll take them in turn. First, things are not as > dire as you state. Certainly one could write a version of fact that hardwired > bigints as you showed. But you need not - here's the original naive > definition: > > (defn fact [n] > (if (zero? n) 1 (* n (fact (dec n))))) > > Such logic that doesn't specify one of the components (in this case, n) is > still polymorphic, as are operations with mixed components. So the power is > in the hands of the supplier of n: > > user=> (fact 10) > 3628800 > > user=> (fact 40) > java.lang.ArithmeticException: integer overflow > > user=> (fact 40N) > 815915283247897734345611269596115894272000000000N
That's fine for fact, but as a consumer of library functions, how do I know when I should pass in bigints? How do I know when an intermediate value, for my particular combination of parameter values, is going to overflow? Should I just use 'N' on every number to every function? This proposal destroys the black-box nature of functions, and seems to me to be the easy solution rather than the best solution, which, I acknowledge, might be very hard work, possibly involving every such function having 2 polymorphic variants, one generic boxed form and one unboxed form, automatically selected and call-site-cached like OO dispatch. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 If you pick up a starving dog and make him prosperous, he will not bite you. This is the principal difference between a man and a dog. -- Mark Twain -- 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
