There are many cases where you just want to use some other tool like
`#:break' to stop the iteration, so no need to make up a bogus stop
value and no need to spend time checking it.
Mainly reogranize the code + exports + docs of the additional list
convenience functions.
Also, add a custom printer to a "running" struct in
`racket/private/promise', so there's a sensible output if the value
happens to leak outside of a promise (eg, when debugging).
Creating a stand-alone executable could slow down a program,
because bytecode embedded in an executable was not treated
in the same way as bytecode loaded from files. The difference
was in on-demand parsing of bytecode --- and now it's enabled
for embedded bytecode, too.
The revised `explode-path' runs in time proportional to the
length of the path, instead of quadratic in the number of
path elements. The difference doesn't matter much in my
program, but I'm reluctant to leaving the implementation
as quadratic (which is forced by using `split-path').
The `#%module-begin' of `racket/base' and `scheme/base' now introduces
a suitable `configure-runtime' submodule, instead of using the
`module->language-info' path.
A submodule is a lot easier to work with, as illustrated by the
removal of the `racket/private/lang' and `scheme/private/lang'
languages.
Also, add `#%printing-module-begin', which is the old `#%module-begin'
(i.e., the one that doesn't introduce a `configure-runtime' submodule).
A language can now introduce a `configure-runtime' submodule that
is `dynamic-require'd before the enclosing module.
This new submodule protocol provides a more general and
easier-to-understand way of configuring the run-time environment for
a module's language, as compared to the `module->language-info'
path (through a `get-info' function, via a 'configure-runtime value,
and finally loading the specified module).
The `module->language-info' path remains in place, and it is
checked after a `configure-runtime' submodule is run, since
that order is likely to be the most backward compatible.
These exception types are intended as a hook for a programming
environment to recommend packages that can provide a module that isn't
found (through an uncaught-exception handler). The new exceptions are
generated by the default module name resolver and defaultload
handler. In addition to the exceptions, there's a new
`prop:exn:missing-module' property and `exn:missing-module?', which is
what an environment should use to detect relevant exceptions.
There's also a new `current-module-path-for-load' parameter, which
just provides a commuincation path from the module name resolver to
the the load handler. The parameter is a relatively ugly piece of the
puzzle, but it's the best I could find to squash the new functionality
into the existing stack of handlers.
... when PWD is defined and when it refers to the same directory
as the result of getcwd().
A shell sets PWD before starting Racket to communicate a preferred
way of referring to the current directory, which may involve soft
links that are not reflected in getpwd().
Swap order of argument for `environment-variables-get'
and `environment-variables-set!', so that the environment
variables come first --- which follows the usual order.
This change means that the parameter isn't used to get
the default environment variables, but that seems ok; the
convenient interface is `getenv' and `putenv'.
On Windows, case-normalized environment variable names.
Also, change the implementation to use an immutable hash
internally.
By default, a sandbox gets a fresh environment variable set,
which means that it does not affect environment variables
outside the sandbox (which means that sandboxed code cannot
set the Racket process's OS-level environment variables).
Closes PR 13667
The `current-environment-variables' parameter determines the current
mutable "environment variable set". If that set is the initial one for
a Racket process, then using the set corresponds to working with OS
environment variables. Otherwise, it's really just a hash table that
is packaged up as OS environment variables if a subprocess is created.
The new environment-variable interface works in terms of bytes, instead
of assuming that environment variable names and values fit in a string
encoding.
The string-based `getenv' and `putenv' are still available as
convenience wrappers. The checking on environment-variable names
for those wrappers is a little tighter, preventing any attempt to use a
name that contains "=".
