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.
It seems to me that there are serious questions about the utility and appropriateness of the exact/inexact distinction. As formulated in R5RS, it is consistent across numbers and numeric operations. The consistency breaks down though, around the edges of that domain, where inexactness would cross into other types (inexact booleans, inexact flow of control, etc). And the standard, with an eye toward permitting certain shortcuts, doesn't really require a fully consistent implementation. The problem with exactness and inexactness, it appears, is that many implementors don't feel that it's worth implementing fully. And they have a point, I guess, in that a full implementation of it (fully orthogonal to type information) adds overhead to each and every fundamental mathematical function. If you implement it fully, it may be true that math in general can only happen, at best, at about 2/3 the speed of math in other languages, and a lot of implementors see that as an unacceptable cost. So they usually make the dodges and hacks that the standard fails to forbid, specifically making exactness correspond to representation type information rather than being orthogonal to type. That fulfills the letter of the requirements, but does not correspond to the most consistent interpretation of the standard. And a lot of people want to "fix" the standard by canonizing this less-consistent view, or some other less-consistent view, and I've listened to the arguments of several people now who want to treat exactness specifically as representation type information in various ways. My response is this; if you don't want to *allow* exactness that's orthogonal to representation type, I don't think there's any purpose in having exactness at all. R5RS *allows* the exactness-as-type interpretation, but it's a dodge; exactness is clearly useless if that's all that it's *allowed* to be. If you mean to use type predicates instead of exactness predicates, just use them. If you want to have functions use exactness as type signatures and balk at the idea that people should be allowed to report exactness whenever they can mathematically prove it because it messes up your Hinley-Miller type inferencing and requires you to dispatch on the "return type", you didn't want exactness in the first place; you wanted type information (and incidentally, you are reading Hinley-Miller in too restrictive a way; your problem is equally solved by treating the exactnesses as additional arguments and an additional return value). Furthermore, treating exactness as type information actively messes up people who are trying to use it as exactness; having different numeric ranges and precisions for example, for exact and inexact numbers leads to all kinds of inconsistencies and problems. For example, when you have A and B such that A < B but both are above the range of representable inexact numbers, and you use infinities rather than error objects, you have this situation: (< (* 3 A) B) => #t (> (exact->inexact A) B) => #t And although the standard *allows* it, mathematically, that's just ridiculous, on a par with having all inexact numbers equal to -19 or something. And the question comes down to this; in view of the widespread rebellion against fully implementing exactness among scheme system authors, and the harm caused by conflating exactness with type, should exactness remain part of the standard? Because if we explicitly make it into mere representation type information, we really should get rid of it entirely because it then misleads and confuses by implying functionality that isn't there. Or maybe we should make the whole concept optional, and explictly forbid any exact/inexact distinctions at all except in implementations where it really *is* information orthogonal to representation type. I'd like to see more full implementations of exactness, but I'm not going to recommend that the standard actually require it; this appears to be a situation where making a demand that very few would bother to implement would just undermine the authority of the standard. Bear