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
