On 18/06/2010, at 4:28 PM, Richard Newman wrote: >> This imposes too high a burden on any programmer who cares about safety. >> >> Don't buy it. That's the whole point of BigInt contagion. If fact and foo >> are correctly written this will work. > > It only takes one library to screw up, and the whole stack falls down. > > Screwing up can occur because of omission (fact being written with a "1", not > "1N", and not being tested with large inputs), or by design. > > This whole debate arose because people care about the speed of their numeric > functions! The safety bignums (which make things slower) will be omitted for > performance reasons, or by accident, and people won't obey the contract of > the function… or won't be able to because of the complex interactions between > libraries. I can't control where every value in my program goes. > > In Clojure as it stands now, those edge cases would see a small performance > penalty as bignums occurred (and then it would go away if they got demoted!). > After this change, a one-in-a-million collision of numbers and > performance-oriented programming would throw an exception with no way to > recover from higher up the stack. > > A programmer who really cares about safety would thus indeed have to shoulder > a massive burden: either review and get complete test coverage over every > library in their dependency stack, or ensure that no non-bignum can ever > enter a library function. I guess that also means no strings, no file sizes, > no URLs, no values which might get recombined… because any of those values > could produce a non-bignum and enter an unsafe Clojure library function, > causing an overflow with no possibility of continuing. (This ain't Common > Lisp.) > > Having digested Rich's notes, pretty much the only thing that I disagree with > is the lack of automatic bignum promotion/demotion. It seems like too much of > a bad tradeoff, sacrificing one of Clojure's selling points for a little > numeric performance. Thus far, Clojure has done pretty well in lexically > scoping its "please make this fast and unsafe" bits — primitive calls, loop, > transients. This would break that pattern.
+1, what I've been trying to say. > I wonder: is there's a middle ground, where primitives are automatic almost > everywhere, but bignum promotion on overflow is still possible? That's what I was suggesting by having two versions of functions, one with primitives and one with boxed values. I did some investigation on this for a Smalltalk JIT using LLVM, in the form of partial specialisation e.g. dynamically generating type-specialised versions of functions (methods in ST) and using the types available at the call site to dispatch - which is more obvious in Clojure because we already have multi-method dispatch. For Clojure you wouldn't test all types, it could just be a binary choice of all primitives where expected or not Of course where a type-specialised function calls another type-specialised function you can avoid the dispatch entirely because you have the type information at the call site. This way, you can pay for the type-driven dispatch once at the start of a computation and end up doing minimal testing (basically dynamically checking that type invariants are maintained e.g. args haven't been promoted in the case under discussion). IMO this is speed + safety. Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Reflecting on W.H. Auden's contemplation of 'necessary murders' in the Spanish Civil War, George Orwell wrote that such amorality was only really possible, 'if you are the kind of person who is always somewhere else when the trigger is pulled'. -- John Birmingham, "Appeasing Jakarta" -- 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
