ghc has a FFI for C and C++ can be made to generate C compatible code. There is no way to use a C++ library in another runtime without writing a big chunk of glue code. Immanuel
On Mon, Mar 17, 2025 at 6:31 PM Hans Åberg <haber...@icloud.com> wrote: > > > On 17 Mar 2025, at 11:01, Aura Kelloniemi <kaura....@sange.fi> wrote: > > > > I am developing a tool for processing musical notation in Haskell. I > want to > > be able to import LilyPond scores and as I don't want to parse LilyPond's > > surface syntax and write a Scheme interpreter, I have decided to export > > LilyPond scores as S-expressions (which are easy to generate in Guile). > > > > The process works such that my import routine invokes LilyPond with a > custom > > init file, which runs the S-expression export routine. > > > > The command that my importer uses is: > > $ lilypond --init /absolute/path/to/init-file.ly relative/path/to/ > score-file.ly > > > > The exporter writes output to stdout. > > > > I have a few questions/problems: > > > > 1) First of all, is this a good strategy at all or would there be a > better way > > to make LilyPond run a custom export code and prevent it from generating > any > > output files itself? I would like my solution to be forwards-compatible > from > > LilyPond 2.24 onwards to some extent at least.. > > In my experience, it is hard to work with source code directly, because of > the difficulty to pin down dependencies. > > GHC has a FFI interface for C++, and Guile has a C interface, so it might > work to call it directly from the Haskell code. What is missing is a direct > LilyPond C++ interface. > https://wiki.haskell.org/GHC/Using_the_FFI > > > > -- -- A man must either resolve to point out nothing new or to become a slave to defend it. -- Sir Isaac Newton
