[plt-scheme] integer-in Contract

I don't think the efficiency will be an issue. Also, if you use
something like the old integer-in a lot, it might make sense for you
to make your own function that takes numbers and returns a contract,
specialized to your use.

As far as the builtins go, I definitely made a mistake in not checking
the arguments more carefully from the beginning, but I think that
probably it is better to require exact numbers for the bounds,
overall.

Robby

On 8/15/07, Doug Williams <m.douglas.williams at gmail.com> wrote:
> 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
> > >
> > >
> >
>
>