* Modernize, improve, reformat, reorganize, etc.
* Use 'null as the default translation for json `null'. Add keyword
`#:null' arguments to control it, and a `json-null' parameter to
change the default. (Note that there is no ambiguity: symbols are
used in hash keys, and JSON restricts them to always be strings, so
`null' can never be a hash key.)
* Properly decode double \u-escape sequences (as UTF-16 surrogate
pairs).
* Add a keyword option to do more string encoding of all non-ASCII
characters.
* Rename `json->jsexpr' (and other way) to `string->jsexpr'. This is
because (a) after using it for a while I still can't remember which
side is which and a `string' in the name makes it clear, (b) it
follows the similar `xexpr' functions.
`port-success-k' is used in a single place, and instead of a simple
`lambda' expression it was used with (and ... (lambda ...)), which lead
to duplication of code. Instead, move the question into the
`regexp-loop' macro. (The compiled zo file is indeed smaller after this
change.)
Although th eoriginal idea was to distinguish "text" paths
from derived filesystem paths, practically everythign that accepts
a module path also accepts a path. Building the generalization into
`module-path?' makes it easier to support `submod' wrappers on paths,
and it seems to fix things rather than break them.
Before this commit, opening collects/drracket/private/unit.rkt required
about 17.5 megabytes of memory and after this commit, it is down to
about 15 megabytes.
The precise measurement I did was to create a frame and a scheme:text%
object in it, record the result of current-memory-use, open the file,
and record current-memory-use again.
For comparison, using a text:standard-style-list% object instead of
the scheme:text% requires only about 4.1 megabytes. One difference
being that there are about 3x more snips (10,204 vs 33,901 (after the
commit)), since we have one snip for each region that has a different
color in the scheme:text version, and the text:standard-style-list has
no colors and thus about two per line (there are 5006 lines in the
file).
The bug happens with n-ary uses of arithmetic operations that
have constant arguments but couldn't be constant-folded ---
maybe due to a divide-by-zero.
