On 29 Sep 2009, at 9:04 pm, John Cowan wrote: >> 2) I really think that exact integers should stay that way up to some >> implementation-specified limit, and then they should raise overflow >> conditions, the handlers of which can then opt to make the arithmetic >> operation return some arbitrary value of their choosing. > > Ooh, so now everyone's going to have to have *overflow handlers* just > because it's *too awful* to do what R5RS specifically allows. Really.
I think it's bad to have multiple different things that (+ 99999999999999999999999 99999999999999999) could do. The result of that should either be 100000099999999999999998, or a condition being raised if the implementation can't stretch to that, in my view of the world. If I can accept approximate answers like 1.000001e+23, then I should tell the implementation this by explicitly asking for it with (f+ 99999999999999999999999 99999999999999999) or some such, I think. I agree that a fixnum-overflow-to-flonum facility is potentially useful; I just feel that the author of some code should be the one who chooses what overflow behaviour they want, rather than the caller of the code, or the person who installs that code on top of some implementation... > >> 4) fixnum/bignum is a side issue that confuses matters. That's just >> an >> issue of representation. Saying a given Scheme "has bignums" or not >> isn't the issue, so I question John's approach to having a feature >> called %bignums. The issue is how big exact integers can get before >> something happens, and then what happens. > > +1. +%bignums really means "report an error when the numbers get > too big". Yeah, I just think it's an unfortunate choice of word; not that I have a better proposal ;-) ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/archives/author/alaric/ _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
