I assume the code generated to check the (integer-in 1 10) contract is similar to what would be used for (and/c integer? exact? (>=/c 1) (<=/c 10)).  In which case the integerness and exactness of the arguments 1 and 10 aren't important, just their real values.  Should the exact integer constraint on integer-in parameters be that strict? Also, even if the exact integer constraint is deemed correct, would the use of -inf.0 (as the first argument) or +inf.0 (as the second argument) allow an efficient short cutting of the lower or upper bounds?  I.e. (integer-in 1 +inf.0) would generate equivalent code to (and/c integer? exact? (>=/c 1)) but would not generate the upper limit test (<=/c +inf.0). Just some thoughts. Doug <div>On 8/14/07, Robby Findler <<a href="mailto:robby@cs.uchicago.edu">robby@cs.uchicago.edu</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I've fixed the docs -- thanks for pointing that out! As far as the contract below goes, I'd guess I'd write:   (and/c integer? (>=/c 1)) to match the old behavior or:   (and/c integer? exact? (>=/c 1)) if you wanted exact integers. Robby On 8/14/07, Doug Williams <<a href="mailto:m.douglas.williams@gmail.com">m.douglas.williams@gmail.com</a>> wrote: > 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?  Or add a positive-integer/c contract that is similar to > natural-number/c? > I assume the best alternative now is to use (and/c natural-number/c (</c > 0)), but I really think (integer-in 1 +inf.0) matches the abstraction > better. > Is there a standard way that others use to denote a contract for a positive > integer? > By the way, the documentation still says integer-in takes two numbers as > arguments and should probably be updated to say two integers.  There might > be a similar problem with the documentation for real-in that should limit it > to real numbers.  I guess those are kind of nits. > Doug > > _________________________________________________ >   For list-related administrative tasks: >   <a href="http://list.cs.brown.edu/mailman/listinfo/plt-scheme">http://list.cs.brown.edu/mailman/listinfo/plt-scheme </a> > > </blockquote></div>