I too think that "correct by default" is a much better idea than "fast by default."
One way I think about this is that the meaning of +, for example, is the sum of its numeric arguments. The performance characteristics are not part of this core meaning, although of course everyone will be happier the better the performance is. Nonetheless, I think that the meaning should be correctly maintained as a first priority, and that means giving the right answer regardless of how many bits are needed. I frequently produce BigIntegers, even in code that's not particularly math-heavy. It has always galled me that in most programming languages any such code breaks because of low-level implementation issues that I don't want to have to think about most of the time. I usually just want the right answer, and I certainly don't want to have to think about the binary representations every time I write code that handles numbers. If I find that my code is too slow then I'll have to think about it, and that's when it makes sense to have to deal with declarations or type hints or special faster unsafe arguments or whatever. Ideally this will take as little work as possible, but I think it'd be a bad approach to make fast free (default) at the cost of saying "but the meaning of + may not actually be numeric sum, and this depends on the number of bits required to represent your numbers, so you better always be thinking about low level representation stuff whenever you use numbers." -Lee On Jun 18, 2010, at 8:10 AM, Laurent PETIT wrote: > I'm no expert in this field. > > What I would like to avoid, is having to become expert in the field to > expect the prevention of more : > > * nightmare debug sessions because of my own code or third party > libraries code > * crash in production code > > which might derive from the choices. > > I tend to think that it seems wrong to require more knowledge from > people wanting to write *more* correct code than from people wanting > to write faster/performant code. This is were I would place the > cursor. > > 2010/6/18 Carson <c.sci.b...@gmail.com>: >> On Jun 18, 2:44 am, Christophe Grand <christo...@cgrand.net> wrote: >>> With contagious bigints (let's nick name them "safeints" and assume >>> they are not BigInteger but something à la kawa) a single N on >>> literals or having all your inputs going through a safeint conversion >>> would trigger safe computations (unless you try to call a static >>> primitive-hinted fn but the compiler would then bark). >> >> I think the example >> (defn bad-twice-fact [n] (fact (-> n fact range last inc))) >> shows it takes more than safeint conversion of arguments to the >> "surface" function to trigger safe computations. All functions called >> by the "surface" function needs to have their arguments converted to >> bigints too, and their return values probably, just in case. Although >> I'm not sure if even that's enough without auto-promotion (if I >> understand auto-promotion correctly...). But note the example doesn't >> even use any type hints or explicit conversion to primitives (the >> point is the conversion may occur as a legitimate side effect of doing >> something else). >> >> *Still*, I'm in favour of fast by default, with an *easy* way to make >> things safe as an option. >> >> >>> >>> Of course a rogue fn can still internally convert to primitives and >>> overflow but you can't do anything to protect you from that. >>> >>> As for mixing several numebr representations in a single collection, I >>> think it's a problem of normalizing data but most of the time your are >>> either in safeland or in fastland so your representations will be >>> homogeneous (safehints or (boxed) primitives). >>> >>> A middleground may be to keep the semantics proposed by Rich but: >>> * integer literals default to safeint (unless suffixed by L for long) >>> * scientific notation and decimal literals default to double (unless >>> suffixed by M or N) >>> * implement a better bigint. >>> >>> Christophe >>> >>> -- >>> European Clojure Training Session: Brussels, 23-25/6http://conj-labs.eu/ >>> Professional:http://cgrand.net/(fr) >>> On Clojure:http://clj-me.cgrand.net/(en) >> >> -- >> 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 > > -- > 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 -- Lee Spector, Professor of Computer Science School of Cognitive Science, Hampshire College 893 West Street, Amherst, MA 01002-3359 lspec...@hampshire.edu, http://hampshire.edu/lspector/ Phone: 413-559-5352, Fax: 413-559-5438 Check out Genetic Programming and Evolvable Machines: http://www.springer.com/10710 - http://gpemjournal.blogspot.com/ -- 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
