On 30/04/14 13:54, Alaric Snell-Pym wrote:

> I'd argue that overflow-to-flonum is questionable (it produces incorrect
> results rather than no results, and lets you check for incorrectness
> with exact?, but I foresee lots of code not thinking to check for exact?
> and silently failing); it strikes me as useful to allow developers to
> have mental rules like "exact + exact = exact". I think that people who
> don't mind exacts overflowing to inexacts are probably people who wanted
> inexacts in the first place and just happened to get an exact when they
> typed "10".

I have been thinking further about the needs of users who don't need
exactness but sometimes get it due to exact literals or things from
(read) and so on, and for whom a "overflow raises a condition" situation
would be annoying (requiring them to laborious cast all their inputs to
inexact, and risk missing one).

I considered having an "exactness mode" parameter, reminiscent of the
FPU flags you can set on x86 processors, but that would suck and be hard
to implement efficiently.

I think perhaps the best way is to provide two libraries full of
identically-named arithmetic operators, one of which overflows to
inexact and one of which overflows to a raise condition.

Thoughts?

Which ones are required by the standard, of course, remains another
matter, but it lets code declare its requirements unambiguously!

ABS

--
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports