>
> 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
