John Cowan <[email protected]> writes: > 1) Should R7RS-large require arbitrarily large (up to implementation > restrictions like memory) exact integers?
Yes. Mathematically correct behavior should be the norm, performance issues the special-case. > 2) Should R7RS-large require support for exact rational numbers? Yes. As above. > 3) Should R7RS-large require support for exact complex numbers? No. I'm not aware of convincing use-cases. It was also not required previously, and there are significant implementations that don't support it. > 4) Should R7RS-large require inexact complex numbers? Yes. These are useful in certain domains, and widely supported. One may ask why all these shouldn't be optional modules like everything else, but problems pop up like 1) if a numeric type is supported, there will probably be reader syntax for it as well, which generally can't be enabled with an import (which will usually be processed after parsing), 2) overwriting bindings for +, -, etc. is strange, 3) I shouldn't need an import or anything to get mathematically correct behavior in my program, IMO it should be the norm. It's unfortunate to marginalize embedded systems, but I'd rather see them e.g. mentioned in an appendix as a special case instead of complicating the main body of the standard. Taylan _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
