Brad Lucier wrote:
> No finite quotient ring of the integers is an ordered ring...
> so the operations that rely on order, namely,
>
> fixnum>
> fixnum<
> fixnum>=
> fixnum<=
> fixnum-positive?
> fixnum-negative?
> fixnum-max
> fixnum-min
>
> don't make sense.  I suggest they be removed.
>
> Once they *are* removed, then there seems to be no reason
> to have (now partially) parallel definitions of fixnum-*
> operations, most of which do *exactly* the same thing as
> their fx* counterpart.

You have a good point.  If the fixnum operations end up
in a different library from the fx operations, however,
it would be annoying to have to import the fx library
just to obtain the ordering procedures, which do make
sense when regarded as specializations of the generic
ordering procedures to the distinguished fixnum
representatives of the quotient sets.  It would also be
annoying to have to exclude the ordering operations of
one library when importing both.

> The presumed fixnum-* operations, which claim to operate
> on a ring, rely on an ordering doesn't satisfy these
> properties.  Without these properties, flow analysis,
> stated as one of the motivations of this SRFI, of
> inequalities is useless.

Your point, I believe, is that it would be incorrect for
the author of a flow analysis to assume fixnums obey the
algebraic laws of an ordered ring.  That does not, however,
imply that flow analysis cannot ever use the results of
fixnum inequalities.  For example, a compiler can
legitimately rewrite

    (if (fixnum<= 0 i n)
        (g (- n i))
        (h i))

as

    (if (fixnum<= 0 i n)
        (g (fixnum- n i))
        (h i))

on the basis of flow analysis.

Will