Implementing a thorough `clean` target for a repo-based is tedious and
error-prone. Instead, make the `clean` target suggest `git clean -d -x
-f .`, which is more effective in most situations (but seems too
dangerous to run automatically).
The `call-in-continuation` function generalizes applying a
continuation to values by accepting a thunk that is called in the
restored continuation. In other words, insteda of having to use the
pattern
((call/cc (lambda (k)
.... (set! saved-k k) ...
(lambda ()
original-result))))
...
(saved-k (lambda () new-result))
The extra call and thunk on the capture side can be omitted:
(call/cc (lambda (k)
.... (set! saved-k k) ...
original-result))
...
(call-in-continuation saved-k (lambda () new-result))
At the Chez Scheme level, a `call-in-continuation` in tail position
within a function can avoid forming a closure for its second argument.
The `call-in-continuation` function at the Racket CS level doesn't yet
provide that benefit.
The `call-in-continuation` operation is called `continuation-slice` in
Feeley's "A Better API for First-Class Continuations".
Expansion of a procedure with keywords is quadratic due to generating
a nested sequence of `let`s, but speed it up by roughly a constant
factor by using a dintinct symbol for each nested layer.
Related to #3070
Using `call-in-continuation` to apply a thunk within a continuation
slightly simplifies and speeds up parts of the implementation of
delimited continuations.
The expansion of `struct` created far too much code to parameterize
`struct-field-index`, making expansion of a `struct` form with just
100 or 200 fields take a noticeably long time to expand.
PR #2678 unintentionally removed this attribute, but it was used
at least by "collections-lib" and "static-rename-lib".
cc @sorawee @lexi-lambda @jackfirth @rmculpepper
- reword the first-page explanation of chaperone contracts;
try to give a positive description by talking about wrappers first
(rather than starting with what chaperones maybe don't do)
- name the recognizer functions for chaperone & impersonator contracts
(on the first page)
- clarify that `contract-projection` and `contract-val-first-projection`
are bad --- that there's a preferred alternative
- describe the outputs of `contract-projection` and
`contract-val-first-projection`; their docs were identical before, but
now re-use prose from sec 8.7 (Building New Contract Combinators)
Use a consistent style for the "good / bad" examples:
- start the code at the far left of each box
- keep a little space between the top of the box & the label
GitHub's CDN seems to have recently started returning the `Location` header for a redirect with a lowercase `l`, which breaks the redirect logic. The HTTP spec says that header names are case-insensitive, so we need to look for either version.
Make `register-process-global` check for byte strings, and avoid
retaining the byte string that it's given (in case that changes, for
example).
Closes#3053
Building glib-specific support into the main Racket executable is
unsatisfying, but it's consistent with Racket BC, and the alternative
is especially tedious to deal with places and namespaces and
allocation.
