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
