John Cowan <cowan@mercury.ccil.org> 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

--
You received this message because you are subscribed to the Google Groups "scheme-reports-wg2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheme-reports-wg2+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.