and/c, and between/c (which implies <=/c and >=/c) so that they turn
themselves into integer-in when appropriate
for example, (contract-stronger? (integer-in 0 4) (and/c natural? (<=/c 4)))
returns #t
- positive-integer?
- negative-integer?
- nonpositive-integer?
- nonnegative-integer?
These are like their exact-* counterparts provided by racket/base,
but they work for inexact numbers, and not just exact ones.
Fix problem with once-use tracking and delayed variable-use marking
that is performed for local function bodies. A delayed variable-use
registration might happen after a once-used variable is replaced by
its use.
This scenario is difficult to provoke, because the optimizer has to
first decide not to move a once-use function, and in a latter pass
decide to move it after all. There's not enough information to
retract the tentative use plus its transitive implications.
The solution is to avoid the generic once-use layer for `lambda` forms
whose uses are delayed (and that likely has a good effect on inlining
anyway). The other half of the solution is to avoid transitive use
marking on a once-used variable whose expression has been moved (and
there are no transitive things to skip, because that expression isn't
a `lambda` form).
It appears that Mac OS wants `RTLD_LOCAL` in the dlopen() call,
otherwise dlsym() searches through all previously open shared objects
– even though dlopen() is given a specific library handle.
The previous for/fold/derived examples in the docs
incorrectly expanded, placing the entire body of the
user defined for loop into a let expression inside of
for/fold/derived. This meant that break clauses (i.e. #:break
or #:final) that appeared in the body of the user-defined
for loop were not visible to the underlying for/fold/derived
macro after expansion and therefore usages of #:break or #:final
incorrectly resulted in syntax errors (since with the incorrect
expansion, they were seemingly misplaced keywords inside of a let).
With this PR the for/fold/derived examples in the docs now
expand correctly into a form that mirrors the actual
expected syntax of for loops:
(user-defined-for (for-clause ...) body-or-break ... body)
==(now expands more or less into)==>
(for/fold/derived (for-clause ...) body-or-break ... body)
Or in other words, the body of the user defined for loop now correctly
expands directly into the body of for/fold/derived.
The expr/c syntax class, as well as its underlying implementation
function, wrap-expr/c, previously produced misleading error messages.
The main purpose of these tools is to ensure a user-provided expression
conforms to a macro-provided contract. However, contract errors produced
by these forms were consistent with situations where both value and
contract were provided by the same party.
This fixes the discrepancy by changing how these forms assign blame to
emulate contract errors that arise from improper function arguments,
since most expressions provided to macros are semantically similar to
function arguments. All examples within the documentation itself
reflect this use case.
These changes alter the contents of error messages raised by expr/c and
wrap-expr/c, which could theoretically break some test suites, but it’s
extremely unlikely that any non-test code would depend on the precise
wording of contract error messages, and the interface is otherwise
completely backwards-compatible.
fixes#1412
