[Haskell-cafe] dynamic code compilation and loading

[Evan Laforge]

On Mon, Jan 16, 2017 at 11:16 PM, Dennis Raddle <dennis.raddle at gmail.com> wrote:
> I'm not clear on everything you've saying.
>
> My program, at present, opens some MIDI ports and leaves them open while it
> is running. It presents me with a command line prompt from which I can
> configure the program and initiate MIDI playback. I can also halt playback
> in progress. Every time I change the score (in the Sibelius typesetter
> program), I initiate a new playback action.
>
> What you are saying sounds like running the program once for each playback.
> I guess the program wouldn't leave the MIDI ports open, as it has to close
> them before it exits. But that should work fine. I would also need a
> different way of configuring the program -- the current settings would have
> to be stored in a file so they won't be lost when the program exits.

I was thinking you'd have ghci running persistently.  Start it up, run
the initialize function which will configure MIDI.  Then every time
you want to process a score, just rerun the "process" function.

> I wonder about two things. First, I would like the majority of the program
> to be compiled. It needs speed. Is there a way to compile everything but the
> module that "varies" a Score?

Yes, you can compile modules and ghci will load the compiled version.
When you change one and do a :r, it will recompile the changed module
and its dependents.  Normally it uses bytecode for this, but you can
also have it compile to binary.  See the ghci section of the ghc
manual.

> Second, the Vary.hs module would need to be located on the disk in the same
> directory as the music score, to keep things organized. But on my disk
> (MacBook Pro with SS drive) there is one tree for Haskell source,
> /Users/Dennis/haskell. I use the option "-i/Users/Dennis/haskell" which
> compiling or running ghci. The musical scores are all stored in a different
> tree, "/Users/Dennis/Dropbox/music/comp".
>
> So I don't know how to "import" a file that is not in my Haskell source
> tree, and more important, is not determined until run time.

You can set flags from ghci, so you can add a -i at runtime.  :l also
understands plain paths, so you could give it the complete path, or
generate it via :def.

> Oh yeah, I don't specify the specific score when I run my program, but
> rather let it search the /Users/Dennis/Dropbox/music/comp tree for the most
> recently modified score. This is convenient, because over the course of an
> hour or two that I compose, I would switch several times between scores, and
> as soon as I modify and save a particular score, that one becomes the source
> for playback.
>
> So the program would locate a recently modified Sibelius score, say
> $MUSIC/piano/tocatta1.sib. (Where $MUSIC is
> /Users/Dennis/Dropbox/music/comp). Then the program would assume there is
> some Haskell source in the same directory, called "toccata1.hs". This source
> would contain functions that vary the expression in ways I like for that
> particular composition.
>
> Does this sound doable with ghci? Or the GHC API?

ghci has some limited but surprisingly flexible scripting ability.
For instance, you could do :def L (\_ -> loadNewest), and then define
a loadNewest function that looks for the relevant .sib file and emits
the path to a parallel .hs file.  I actually use a :L macro to load
the currently edited file in vim, so I'd probably make a vim macro to
load (or create) an .hs for the "current" .sib file, and then use :L
to load it.  For interactive work, my :l is overridden to :m +Utils so
I can get a bunch of interactive utils without having to import them
into every module.

Also, you are not limited to just rerunning a single "vary" function.
You can use the full power of haskell to configure the realization.  I
use the REPL for analysis and debugging as well.

> About what I've learned about expression score realization, I could perhaps
> share some things at some point. Unfortunately I have bad work habits... I
> often don't take care to finish projects in a way that is presentable, so I
> have many years of half-finished compositions that can't even be played back
> with the current version of my program. I'm 48 years old and finally
> realizing just how important it is to organize and finish things. And to
> collaborate. I found another musician to collaborate with -- I will make
> computer "interpretations" of his compositions.

I keep each score saved with a "known good" version of the MIDI
output, along with a commit ID for the time it was generated.  So it
not only archives a known good realization, it also acts as a
regression test against code changes (checking all saved scores is
part of the commit validation, in addition to the more usual unit
tests), and if all else fails, I can get back to the original
performance by rewinding the repo.  mp3 is good for archiving of
course, but you'll never be able to change it again.