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