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.
This makes it correspond to the license page we have on downloads that
talks about the "lesser" GPL rather than the "library" one.
Also, change the file name to have a more friendly .txt suffix, and add
some more responsible properties for things in doc/release-notes.
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
- the `lam' structure from `compiler/zo-struct' changed to include a
`toplevel-map' field
This change helps solve a finalization problem in `racket/draw',
which in turn sigificantly reduces the peak memory use of `raco setup'
during the doc-building phase (because some documents load `racket/draw'
to render images, and multiple copies of `racket/draw' were retained
before finalization was fixed).
The change is an extreme way to solve a specific finalization
problem, but it's a kind of space-safety improvement; space safety
almost never matters, but when it does, then working around a lack of
space safety is practically impossible. In this case, it's not clear
how to otherwise solve the `racket/draw' finalization problem.
The improvement doesn't change the representation of closures, but it
requires special cooperation with the GC. All closures in a module
continue to share the same array of globals (plus syntax objects);
that is, instead of completely flat closures, Racket uses a two-level
environment where top-/module-level variables are grouped
together. The code half of a closure now records which
top-/module-level variables the body code actually uses, and the mark
phase of GC consults this information to retain only parts of the
top-/module-level environment frame that are actually used by some
closure (or all of the frame if it is accessible through some other
route). In other words, the GC supports a kind of "dependent
reference" to an array that is indexed by positions into the array
--- except that the code is more in the "Racket" directory instead of
the "GC" directory, since it's so specific to the closure
representation.
