My application needed the flexibility of writing test code and running it, or configuring its job (playback of music) through Haskell code and immediately testing the result (i.e. making sound and listening). I thought I would use GHCI, but I ran into some trouble. For one thing, my program forks a thread to do the timed control of the music, while the main thread implements a REPL-like "control loop" -- i.e. let me enter commands to influence the playback or halt it. I think this was crashing GHCI, perhaps when an interpreted script forks a thread which is still alive when control returns to the GHCI prompt. Not sure. Anyway here's what I did. Now the process that does real-time control of the playback is an entirely separate process. The control loop is started by me first, and depending on the command I enter, it builds the playback program with "ghc --make" and then spawns it. I send it signals from the control loop. This turns out to be great. I can make changes anywhere in my playback application, from the deepest utility library to the top-level configuration script, and it builds as needed before running. And, in the case it doesn't need to build anything, "ghc --make" finishes quickly so it doesn't feel inefficient to invoke it after every command I enter in the control loop. D