It turned out that using a single-process design was not going to work well enough in the long-run. Offloading process management to the front-end is against the goals of Scion, so the new architecture fully embraces the need for multiple processes. See docs/Architecture.markdown for details.
The mechanism to deal with transitive dependencies works only with "cabal install" but not with the local directory "equivalents" for "cabal configure" and "cabal build". So we use "cabal install" to build the server which has the annoying side effect of installing the binary globally (or per user). Instead of only in the current directory. What a mess.
which is taken verbatim if there is no match
Finding a suitable abstraction that works for a variety of protocols is difficult. Maintaining several protocols also probably isn't worth the effort. By using a single protocol we also keep the front-ends completely independent of the server. (Otherwise some front-ends may end up broken with various versions of the server because some protocol-specific patch didn't make it into the release.) JSON is a simple and very widely supported protocol. It doesn't fit too well with Haskell's or Emacs' type system (e.g., ambiguous encodings) but at least this Hydra has only one head. ATM, the Emacs front-end is mostly broken because the commands are often not encoded correctly, but the server itself should be fine.
This is needed to efficiently implement getLine on top of the chunk-based socket. Possibly network-bytestring should implement this, so we don't have two levels of buffer management.
In particular, server/Scion/*.hs matches nothing, so make tries to find a rule for it. Fixed by being more specific in the dependencies.