[plt-scheme] integer-in Contract

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

On 8/14/07, Robby Findler <robby at cs.uchicago.edu> wrote:
>
> 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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20070815/7360ae20/attachment.html>