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.
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