So far, bytecode for traditional Racket has been kept separate from
RacketCS bytecode by using a different "compiled" subdirectory for
RacketCS. That makes sense for development work to allow the
implementations to coexist, but it creates trouble for packaging and
distributions, and it (hopefully) won't seem necessary in the long
run. Treating the different virtual machines like different versions
seems more generally in line with our current infrastructure.
Rearrange the configure scripts so that it will be possible to build
RacketCS from a source distribution and have it installed in the right
place. Also, when building Racket3m just to bootstrap RacketCS, don't
install Racket3m.
Retains a strong link to a place-channel write end when there's at
least one waiting thread. This is symmetic to keeping a strong link to
the read end when the place-channel queue is non-empty. The change
repairs a problem building documentation with places in `racocs
setup`.
There no longer seems to be any path that uses the 0-arity option for
a read result from a custom input-port that is a function for a
"special" result. Probably, that path got lost when I added a `source`
optional argument to `read-char-or-special`. If so, that effect of the
change wasn't intentional, but let's just be happy that a
simplification is in place.
Refines 2ef8d60cc6 to avoid characterizing the failure as a `(-> any)`
contract on `hash-ref`, since `hash-ref` doesn't enforce that contract
in general. Go back to an `exn:fail:contract:arity` error, but keep
the specialization of the error message to clarify that it's from
`hash-ref`. Also, bring RacketCS into sync.
If I have understood the behavior of ```app``` correctly, the documentation needs to be clarified. Currently it implies that match expects a single result, and one could reasonably infer that the matcher will require that single result to satisfy all ```_pat```s given. The error message resulting from a reasonable-but-wrong pattern like ```(app string->number (? number?) x)``` is inscrutable, so a doc fix is important here.
I have also added an example that illustrates the use case that led me to submit this PR.
