I am testing my collections on the new V371 release candidate and encountered what appears to be a change in the integer-in contract.  I have often used (integer-in 1 +inf.0) as a contract for a positive integer.  With V371 this now gives an error "integer-in: expected two exact integers as arguments, got 1 and +inf.0)".  I can understand the change, but I also like the convenience of using infinities as arguments here.  Would it possible to change integer-in so that it allows -
inf.0 as the first argument and +inf.0 as the second?&nbsp; Or add a positive-integer/c contract that is similar to natural-number/c?<br>I assume the best alternative now is to use (and/c natural-number/c (&lt;/c 0)), but I really think (integer-in 1 +inf.0) matches the abstraction better.
<br>Is there a standard way that others use to denote a contract for a positive integer?<br>By the way, the documentation still says integer-in takes two numbers as arguments and should probably be updated to say two integers.&nbsp; There might be a similar problem with the documentation for real-in that should limit it to real numbers.&nbsp; I guess those are kind of nits.
<br>Doug<br>