# [plt-scheme] integer-in Contract

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 <m.douglas.williams at gmail.com> 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:
*>* http://list.cs.brown.edu/mailman/listinfo/plt-scheme
*>*
*>*
*