On Sep 23, 2009, at 12:24 PM, Ray Dillinger wrote: > Would you be unhappy if there were a distinguished syntax for "bignum" > values in the fixnum range, where fixnums overflow to inexact and > bignums yield bignum results?
Yes. Extremely. I think it's a natural expectation that certain operations (addition, subtraction, multiplication, exponentiation, modulo, division by a whole divisor) return exact integer results when given exact integer inputs. If the implementation can't return an exact answer, I think it's sensible for an error to be raised. Flonums, if IEEE doubles are used, already provide 53 bits of exact integer precision; you can use these as your "fixnums" if you desire inexact results for some operations. Perhaps a lexical marker controlling whether numbers read without an exact or inexact qualifier (#e or #i) are exact would be helpful. Otherwise, I think it's counterintuitive in the extreme to provide an inexact answer when the answer can be represented exactly. Once again, I'm not understanding why bignums are so difficult that they can't be expected from an implementation. Many things about Scheme are tricky to implement correctly; nonetheless, I don't hear arguments that unlimited-extent first-class continuations must go because it's hard to get right or difficult to optimize. Why is exactness-preserving subtraction in a class unto itself? Many Schemes already *do* provide this, and many of them have independent implementations *not* built on one of the existing libraries. The R6RS requirement of a full numeric tower has not prevented multiple new implementations of the R6RS from being created. The same requirement in Common Lisp has not prevented multiple implementations of CL from being created, some of which provide extremely well-optimized numeric performance (including unboxed modular arithmetic on word-sized integers!). The presence of bignums in Ruby and Python has not caused either of these languages to implode. On the contrary, not providing bignums seems to be a relatively rare choice among implementations that purport to implement the R5RS without restriction or limitation. Of the implementations I've looked at, only Chicken does not provide them, and I don't think the reasons behind this decision are particularly well thought out (you're welcome to convince me otherwise). If you're aware of others, I'd like to hear about them. -- Brian Mastenbrook [email protected] http://brian.mastenbrook.net/ _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
