A "prefetch" message is an attempt to trigger parallel builds for
multiple requires in a module. It doesn't work right with `(planet
...)` paths, probably because it doesn't work right with loading
`planet/resolver`.
Insteda of propagating a property manually, allow the
`syntax-track-origin` operation in macro expansion to do it.
Otherwise, properties turn into pairs of duplicate values.
* Remove exn:fail:cookie, since I’d rewritten the library code to
avoid using it.
* Correct docs for cookie-header->alist, to reflect not raising the
exn.
* Remove needless illustration of date from clear-cookie-header
example.
* Add new modules, docs, and tests in cookies/
* Server: parse Cookie header, make cookies, make Set-Cookie header
* User agent:
* parse Set-Cookie header
* save cookies
* make Cookie header
* interface for substituting better cookie storage
* Common functionality: validate cookie parts
* Add deprecation notice to old cookie lib
Test and validation cleanup
When determing whether expressions can be reordered, a reference to a
module-defined variable was considered unreorderable when it is
known to have a value and no further mutation, but the value isn't
constant across all runs.
This reverts commit 005b3f720f.
The expander's definition of "same context" is not flexible
enough, and introducing an extra `#%expression` wrapper
breaks TR's recognition of expanded classes. Revisit in the
near future.
The optimizer had some reductions of predicates applications, like (pair? X),
only when X was very simple and the type of X was obvious.
Use expr_implies_predicate and make_discarding_sequence to allow
the reduction of more complex expressions.
Also, the reduction of procedure? and fixnum? were special cases in
optimize_application2. Move the checks to expr_implies_predicate
to take advantage of the reductions in more general cases.
