I got inclusion of the original init file working with the following code.
IMHO it feels like a very crude hack. Is there a scheme function that would
include a LilyPond file in the current context?
Code:
$(ly:parser-include-string
(format #f "\\include \"~a\""
(string-append (ly:effective-prefix) "/ly/init.ly")))
That is actually the correct/best way to do it right now. There isn't a direct Scheme API for "normal" includes. The Scheme functions for parsing are for other situations, like embedded code blocks, and they won't do exactly what you want.
I was talking about \displayMusic, as my experience with Guile's `write` has
been that it only prints "#<Book>" or "#<Score>" which I considered to be of
not much use.
That's because LilyPond uses custom objects defined using Guile's legacy C++ API, and the Scheme interface of such objects, including their print representation, is fully controlled by the class implementation. Many of these classes implement only minimal Guile interfaces.
> I believe that simply (write foo) where foo
> is a ly:music? captures all the available information, including input
> locations.
It actually does. I was not awareof this. Simple Scheme lists are likely
easier to parse. This format produced by write probably is not meant to be
machine-readable (for example source file name strings are not quoted).
I believe that `write` is meant to output data suitable to be loaded as Scheme code, while `display` is adds quoting to facilitate human readability. However, that only really applies to standard Guile data. LilyPond music expressions are custom property objects defined in C++, and I don't think they can be loaded by evaluating their `write` representation.
> If this were going to be included in LilyPond, you would want a design
> other than an alternate init file, in order to support generating this
> auxiliary output in parallel with print and/or MIDI, similar to the way
> lilypond-book aux files are generated.
I see, and this is not the intention of my exporter. I specifically want to
inhibit all other output generation.
I would actually want to develop this towards a REPL, where a user can
interactively enter music expressions and LilyPond would process them in its
current context and return a machine-readable representation.
LilyPond actually ships with a REPL, but it's a Guile REPL so music expressions would need to be wrapped in #{ #}, and you can't put top level syntax like variable assignments inside #{ #}. However other than that, it does exactly what you want I think. You can run it with `lilypond scheme-sandbox`. I've used this heavily to support features of Emacs lilypond-ts-mode.
Saul