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.
bear <bear@xxxxxxxxx> writes: > It seems to me that there are serious questions about the utility > and appropriateness of the exact/inexact distinction. In my opinion, the virtue of the R5RS formulation is that it works sanely for everybody: the people who want to cut corners, the people with minimal numeric towers, and the people who want everything with every possible bell and whistle, whether valuable or not. > 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. I see no indication that the standard "failed to forbid" this; you treat it as if this is some accident. Rather, I think it was intentional: the standard gives a common language to all these cases, so that programmers can express themselves in ways that do the right thing on all these cases. > That fulfills the letter of the requirements, but does not > correspond to the most consistent interpretation of the standard. What is this "most consistent interpretation"? > 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. I don't want to adopt this view, certainly, because I think the basic structure of this part of R5RS is just fine, thank you, right now. (There are some things that could be tidied up, but no significant alterations seem necessary to me.) But your argument seems to ignore the use of the language as an expressive tool, and focuses only on implementations. The language gives a way to express certain operations cleanly and sensibly, in ways that will then work properly on all the systems which implement the relevant parts of the idealized fully general and orthogonal numeric tower. > 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 (I assume that A isn't negative, right?) :) > 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. This is not a "rebellion"; it is the expected situation. It's just what the standard does: it lets you decide, implementation-by-implementation, which parts you want. So why should exactness remain in the standard? For exactly the reason it's there now: it's a coherent and sensible abstraction, it's named nicely, it works seamlessly with those implementations that *would* do more with it. It doesn't "imply functionality", because the standard *explictly* leaves it up to implementations to decide what numeric functionality they want. > 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. Why do that? > 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. Sure, of course. What's wrong with the status quo then? Thomas