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?
<br>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).
<br>Just some thoughts.<br>Doug<br><br><div><span class="gmail_quote">On 8/14/07, <b class="gmail_sendername">Robby Findler</b> <<a href="mailto:email@example.com">firstname.lastname@example.org</a>> wrote:</span><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!<br><br>As far as the contract below goes, I'd guess I'd write:<br><br> (and/c integer? (>=/c 1))<br><br>to match the old behavior or:<br><br> (and/c integer? exact? (>=/c 1))
<br><br>if you wanted exact integers.<br><br>Robby<br><br>On 8/14/07, Doug Williams <<a href="mailto:email@example.com">firstname.lastname@example.org</a>> wrote:<br>> I am testing my collections on the new V371 release candidate and
<br>> encountered what appears to be a change in the integer-in contract. I have<br>> often used (integer-in 1 +inf.0) as a contract for a positive integer. With<br>> V371 this now gives an error "integer-in: expected two exact integers as
<br>> arguments, got 1 and +inf.0)". I can understand the change, but I also like<br>> the convenience of using infinities as arguments here. Would it possible to<br>> change integer-in so that it allows -
inf.0 as the first argument and +inf.0<br>> as the second? Or add a positive-integer/c contract that is similar to<br>> natural-number/c?<br>> I assume the best alternative now is to use (and/c natural-number/c (</c
<br>> 0)), but I really think (integer-in 1 +inf.0) matches the abstraction<br>> better.<br>> Is there a standard way that others use to denote a contract for a positive<br>> integer?<br>> By the way, the documentation still says integer-in takes two numbers as
<br>> arguments and should probably be updated to say two integers. There might<br>> be a similar problem with the documentation for real-in that should limit it<br>> to real numbers. I guess those are kind of nits.
<br>> Doug<br>><br>> _________________________________________________<br>> For list-related administrative tasks:<br>> <a href="http://list.cs.brown.edu/mailman/listinfo/plt-scheme">http://list.cs.brown.edu/mailman/listinfo/plt-scheme