1. Changed the API documentation for scheme_make_hash_tree, adding primitives for:
* SCHEME_hashtr_eq
* SCHEME_hashtr_equal
* SCHEME_hashtr_eqv
2. Changed direct uses of scheme_make_hash_tree to use these enumed values.
3. Fixed bugs in documentation
4. Defaults to racket/interactive (and racket/gui/interactive) if there is nothing in the config file
Now accepts any whitespace, not just spaces, ignores both leading and
trailing whitespace, and accepts multiple whitespace characters
separating subterms.
This function exposes the fast subset operation that is built in for
immutable hash tables (and used by the set-of-scopes implementation).
Also, make the space optimization implicit for `eq?`-based hash tables
that contain only #t values (instead of explicit and only available
internally). It turns out to be easy and efficient to make the
representation automatic, because the HAMT implementation can support
a mixture of nodes with some containing explicit values and some
containing implicit #t values.
Now with-disappeared-uses surrounds its body with let, so it can contain
multiple body expressions. The record-disappeared-use function is like
record-disappeared-uses but for a single identifier.
When an array value is provided, make sure that it's an array
with at least the expected length (or longer) and same element
layout. That's weaker than checking that the array elements have
the right type, because an `eq?` check at the ctype layer seems
too strong, and the ctype API doesn't provide enough information
for a more flexible equality.
Syntax objects generally make sense as properties in other syntax
objects, but they require special care when marshaling to bytecode
(as syntax objects do in general). To make that special handling
possible and reliable, constrain the shape of allowed values.
The name `path-extension` created a conflict for an existing
registered package, so it should not have been added to
`racket/path`.
Also, `path-get-extension` was intended to work on a path
that is syntactically a directory, so fix and test that.
Change the one expansion mode as far as I can tell) that disables
lifts so that lifts are now allowed, which means that
`(syntax-transforming?)` implies `(syntax-transforming--with-lifts?)`.
The old documentation incorrectly characterized when lifts
were allowed. Ryan noticed the documentation problem, and that
observation led to this simplication.