On Sep 28, 2009, at 11:31 AM, John Cowan wrote: > That strikes me as over-specification. Most people in other languages > don't worry much about the range of the largest kind of fixnums they > have, > and it should not be a requirement that Scheme implementations signal > an error on fixnum overflow -- returning an inexact result should > still > be fine.
Well, *I* don't worry about it because I'm used to using implementations (or languages) with bignums. Can you point to another example of a dynamically-typed language that allows implementations to set a (very small) bound on the largest representable exact integer, and also provides the exact -> inexact overflow semantics of Scheme? I'm not thinking of anything off the top of my head. Most languages with limited integer types provide modular semantics. > But that does mean that it's acceptable to return either exact or > inexact > 2^24 when you add 2^23 to 2^23, which seems to count as meaning > "dependent > on an implementation-specified integer range". What I'm suggesting is that a program should be able to explicitly request overflow-error semantics even on an implementation which normally implements exact -> inexact overflow. Overflow to inexact can radically change the meaning of a program. What are standards for but allowing users to write programs with an expectation that the program will behave similarly on multiple implementations of the language? -- Brian Mastenbrook [email protected] http://brian.mastenbrook.net/ _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
