Hello Moritz,

GHCi is basically just GHC. And you could ship GHC with an initial package-db that contains all of your tidal dependencies, thus removing the need to install more.

Thank you for the idea of using a package-db. When you say initial, do you mean that: We create a package-db that points to the built tidal libraries and make sure our executable can find it, or that this package db can actually be hosted inside the compiled executable at compile time?

Adding additional packages will require cabal/stack or some other way to get and build them though, should that be a consideration.

This would be nice to support, but many users of tidal, such as myself, are not haskell developers. If needed, the current method of using tidal cycles using the haskell package ecosystem is suitable for this usecase. The issue is more that: a musician might be really excited to try tidal cycles but struggle or fail to complete the process of installing a development environment. Many people who give workshops for tidal spend the majority of the time helping with installation! Using a package-db to create an easy-to-distribute nix or MacOS package is a huge plus, but having a portable static binary is a lot more foolproof, and affords lots more interesting use-cases. Another example: packaging tidal as a standalone WASM blob that we can easily distribute as a VSCode plugin. This would allow for a fool-proof one-click install! (to that note, thank you Georgi for the ghc/wasm example)

For your second question, to just “run” a tidal pattern, you should be able to compile this into a standalone (even static) haskell executable I would assume. And then be able to ship that around and run in the final environment.

Unfortunately, this would not work, as the pattern would be authored by the user of the DAW, inside the DAW, and would not be known at compile time. You can find an example of a VST plugin which uses a stripped down version of tidal (with its own parser and execution engine) here: https://codeberg.org/TristanCacqueray/pluguzu --- As a closing note, tidal only really makes sense as a domain-specific language embedded within haskell. So in order to easily distribute or embed tidal, we have to package or embed haskell too! Thanks, Gwen

A similar idea to the recent ghc-in-the-browser (posted by Georgi above) that I had was a Jupiter Notebook. There's a Haskell kernel: https://github.com/IHaskell/IHaskell Have you explored running your app in a Notebook? Other than that, as Moritz says, it's basically the question of creating a custom GHC distribution, which doesn't look fun... -- Best, Artem On Wed, Nov 5, 2025 at 8:46 AM Georgi Lyubenov wrote:

Hi Gwen,

I believe this might potentially be of interest to you as well - https://discourse.haskell.org/t/ghc-now-runs-in-your-browser/13169

Cheers, Georgi

...

Hello!

My name is Gwen and I am investigating an interesting problem related to tidal cycles, a haskell library for patterning music.

https://tidalcycles.org/

We have the desire to distribute tidal cycles without the need for the end user to install a full haskell development environment (ghc/cabal/stack, etc). However, the interface for tidal cycles is a haskell repl.

We essentially want to create an executable that will start a "pre-heated" ghci session which has the tidal libraries loaded, that we can compile on one machine with a haskell toolchain, and run on a system without one. Another use-case would be to evaluate tidal patterns authored by a musician inside of a Digital Audio Workstation.

I am investigating whether this is possible. Does/could the haskell ghc api support this kind of use-case?

If I was to support a similar use-case with a language like janet (which is designed to exist in a host application), the solution would be to host

On 11/5/25 14:34, glfmn via ghc-devs wrote: the compiled bytecode in the application, and populate the interpereter or virtual machine's environment with those symbols so it could find the pre-compiled bytecode hosted inside the executable.

...

Thanks,

Gwen

Links with additional context:

- https://github.com/haskell-hint/hint/issues/156 - https://github.com/haskell-hint/hint/issues/80 _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org

_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org