On Fri, Jun 18, 2010 at 2:20 PM, Rich Hickey <richhic...@gmail.com> wrote:
> > On Jun 18, 2010, at 8:56 AM, Konrad Hinsen wrote: > > On 18.06.2010, at 14:49, Rich Hickey wrote: >> >> I don't see a way around this fundamental dichotomy. The semantics for + >>> should be unified, and the operator that makes the other choice needs to be >>> called something else, or placed somewhere else. >>> >> >> My preference would be "placed somewhere else". We have namespaces, so why >> not profit from them? >> >> My vote would be for: >> >> 1) clojure.core/+ doing bigint promotion and reduction under all >> circumstances (no optimizations that would break the semantics) >> >> 2) clojure.fastmath/+ doing type-specific and optimized addition. >> >> This would retain the "safe by default" approach that I think fits Clojure >> best, and yet make it easy to use the "fast" version everywhere with nothing >> to change but the ns form at the top of a module. >> >> > Which then begs the questions: > > - how will someone 'protect' themselves from libraries written using > fastmath? > > - similar looking code will change semantics when the ns switch is made - > seems dangerous as it might violate the presumptions of the original > authors. > > Rich > > In this situation, I would rather have some kind of toggle *use-bigints-by-default* (defaulted to false) used by the compiler. Then, if someone needs big integers, he can switch the toggle and recompile everything. You wouldn't have to change the libraries ns. As for being predictable, if you have numbers that can be bigger than 10^19, you would probably know it in advance. (indices, counters and the like don't grow that big) -- 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
