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 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...)
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.
- no more attempt to support places with the Boehm GC
- no more libatomic (which was for places + Boehm GC)
- remove unsupported configuration options
- strip Racket-specific configure options before libffi configure
- port two leftover Perl scripts to Racket scripts
and documented and adjusted these libraries:
racket/contract/base
racket/contract/exists
racket/contract/parametric (renamed from exists)
racket/contract/region
because it's often useful to show more values, and a
tail `raise-mismatch-error' instead of a nested `format'
can avoid some safe-for-space work in the JIT output
which creates a little more sharing than the automatic
caching of modules, but only for a program that explicitly
attaches module declarations to share
- bug fixes are related to allocation and runstack space
- a `touch' within a future can complete before the `touch'ing
future is itself `touch'ed
- also make `length' safe (and JIT-inlined)
- rename old `racket/stream' to `racket/sequence', and adjust
to avoid stateful iterations
- add a new `racket/stream' library with a `strean-cons' that is based
on SRFI 41
- adjust `for' and some sequence constructors like `in-range' to
work more directly with streams
- syntax is now (generator formals body ...+)
- add `generator?'
- remove common run-time code from the `generator' macro expansion
- doc fixes
- start test suite
- abstract over JIT inlining of fsemaphore operations
- fix problems with non-parallel fsemaphores
- adjust tests so they don't assume too much concurrency
- clarify fsemaphore vs. semaphore in the docs
by removing a redundant expression in an error message, adding
tests, and documenting the fact that a syntax-error message can
expose the pattern source to users
