Since sets are implemented using the elements as the domain of a hash table,
the following must be true:
* element contracts for (seteq ...) must be flat
* element contracts for (seteqv ...) must be flat
* element contracts for (set ...) must be chaperones, and the resulting
contract is a chaperone contract
Also, change higher-order set/c contracts to be chaperone contracts
due to the new restrictions.
It's not clear that any limit is still needed, and probably
font sizes should be liberalized to reals instead of
integers (but I don't want to spend that kind of time
right now).
requiring itself into the entered namespace.
This makes it useful in some cases where this require leads to a
dependency cycle, eg (enter! racket/list). It's obviously not useful
for use as-is, since you will not have a bound `enter!' to get out of
the namespace (and possibly no `require' to get it) -- but it is useful
for meta-tools like xrepl. This is why the flag is verbose. `xrepl'
now uses this flag.
Also, the check for valid keywords for the form is now done at runtime
rather than in the macro. This doesn't matter in this case, since the
form is intended for interactive use anyway.
Also, separate the two parts of `enter-load/use-compiled' (it was
defined curried, but didn't use it).
Use the new functions in `syntax-case'; the benefit is small, and
it's mostly useful as hint to the optimizer that the operation
can be dropped if the result isn't used
`setup/private/path-utils'.
The API is a little different: instead of getting the alist and the
path, there's a curried function that gets the alist and produces a
function to do the substitutions.
`setup/path-relativize'.
`setup/path-relativize' is freed from a bunch of things that were due to
historical baggage, but some remain. (Also, update its docs.)
by default; a new optional argument restores the old behavior
(but the default behavior is consistent with the old docs and with
the vast majority of existing uses)
The implementation is ugly for performance reasons. A new primitive
`prop:arity-incomplete' property determines when to return #f for
`procedure-arity-includes?' in default mode. A nicer implementation
would be to redefine `procedure-arity-includes?' at the kw-proc level,
but the bytecode optimizer's and JIT's treatment of the built-in
`procedure-arity-includes?' is important. The implementation choice
could be revisited after cross-module inlining is implemented.
Closes PR 11978
the first function's arity is 1, avoiding another `call-with-values'.
The difference in timing is in the noise (looks like `call-with-values'
is optimized for an arity-1 receiver), but it seems more in line with
the rest... Incidentally, it steps around the problem in PR11981.
The new version fixes some problems with the previous one, most notably
it can create a keyworded function when the last input is is keyworded.
`compose1' is a restricted variant that requires single values in the
composed pipeline -- besides being potentially faster (probably more
if/when there is cross module inlining), it has a semantical
justification, similar to the restricting function call arguments to
return single values, with similar robustness benefits. The
implementation of both is done in a generalized way, and the results can
be faster for both `compose' and `compose1'. (Not by much -- 20% and
30% resp.)
One thing that it could do is to reduce the resulting arity to match the
last given function. I didn't do this since it adds a significant
overhead to the result. (No strong opinion on doing that...)
so the error is actually printed instead of swallowed silently.
Also, fix some copy/paste uses of 'make-evaluator instead of
'make-module-evaluator in error messages, and two more in
`make-evaluator*' that lacked a "who" input.
Actually, the new `thunk' is a nullary function, which I think is very
popular expectation for the name. Since there are possible uses for the
any-arity version, it's added too, as `thunk*'.
because the previous documentation didn't actually define the form;
the examples were good, but epecting a reader to infer meaning
from examples wasn't good enough. The use of a `module-path?' contract
in the old docs wasn't appropriate; contracts apply to values, while
grammar productions should be used to document syntax constraints.
Also, `module-path?' was too permissive (only literal strings and
identifiers are actually allowed), while the actual syntax allows
either a single path or a sequence.
so that they conceptually apply after the current
transformation, instead of before the current transformation;
more general rotation problems were related to aligned drawing
and the calculation of the effective scale for alignment
--- originally left out on purpose for performance reasons,
but it was not documented as missing a test, it's obviously
better to check for a list, and JIT changes have made
the `list?' test inexpensive
and documented and adjusted these libraries:
racket/contract/base
racket/contract/exists
racket/contract/parametric (renamed from exists)
racket/contract/region
