This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.
Marcin 'Qrczak' Kowalczyk <qrczak@xxxxxxxxxx> writes: > Thomas Bushnell BSG <tb@xxxxxxxxxx> writes: > >>> Why not the other way around: that the default behavior is known, >>> and implementations may provide other fancy choices which must be >>> turned on explicitly? >> >> Nope. We should maintain consistency over time in the meanings of the >> functions. It is not a decent idea to have the next RnRS standard >> specify addition in a way which is fundamentally incompatible with its >> predecessors. > > It's compatible with existing practice. It's not. There may actually be programs out there that depend on exact division doing the mathematically right thing. You want to break them all? > (The difference between fixnums and bignums should not be exposed > except perhaps by some weird functions used as an efficiency hack. > Other representations are important though.) See, this is where you're wrong. Constant-width addition is valuable for integers too, not just floats. But when people doing integer arithmetic want that, it's an "efficiency hack", and when you want it for floating point, it's Absolutely Essential. Very well, I agree. It *is* essential. So, let's discuss the best way to provide it, rather than this silly discussion. I think the best way to provide it is by functions that cleary specify which behavior they get, preserving backward compatibility with the existing standard. Thomas