On Jun 18, 4:22 am, Nicolas Oury <nicolas.o...@gmail.com> wrote: > On Fri, Jun 18, 2010 at 11:47 AM, Carson <c.sci.b...@gmail.com> wrote: > > Don't buy it. That's the whole point of BigInt contagion. If fact and foo > > > are correctly written this will work. > > > BigInt contagion doesn't help if in some convoluted manner a BigInt's > > value is used to construct a primitive sufficiently large that later > > causes an overflow. > > > I would like to see that in real examples. And not in something that tend > > to be mainly a program that crunch numbers. > (I think a program "about numbers" could take a bit of complexity to handle > numbers. > If you write a program to that generates web page, you agree to have an > html library and not have "every structure in clojure is html".)
I agree! Sorry I have no real examples, just my contrived example. But note the example I used isn't *that* contrived, in the sense that it doesn't use any type hints or explicit conversion to primitives to cause an overflow on purpose. The point is that the overflow may occur as a legitimate side effect of doing something else, whereas it currently will not. And *still*, I'm in favour of fast by default, with an *easy* way to make things safe as an option. The key is to make the safe option *easy*. > On the other hand, programs that have few number computations - mainly to > handle a few stats and indices - but that are spread in a lot of code > (I think most program are like that) should benefit from good performance > without annotating all the code. -- 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
