[plt-scheme] integer-in Contract

From: Robby Findler (robby at cs.uchicago.edu)
Date: Tue Aug 14 20:03:46 EDT 2007

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


Posted on the users mailing list.