Hi Gwen,
Fair warning: The devil will be in the details.
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.
Adding additional packages will require cabal/stack or some other way to
get and build them though, should that be a consideration.
This path would essentially be building a derivation of a GHC distribution.
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.
Happy to bounce off a few more ideas if you want.
Best,
Moritz
On Wed, Nov 5, 2025 at 8:35 PM glfmn via ghc-devs
Hello!
My name is Gwen and I am investigating an interesting problem related to tidal cycles, a haskell library for patterning music.
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 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