When I was toying with Haskell I was unable to get GHCi to interpret multiline definitions (Haskell is declarative, which means you don't make commands, but you declare commands which then get executed).
Jupyter+conda/anaconda is almost always not installable and broken for most of its kernels (it was for Haskell), so I ended up piping GHCi to a websocket server that I found on GitHub and a minimal HTML/JS frontend to talk to it: a reorderable list of textareas.
Then I added some security in the form of passing and verifying long random strings (via files, URL arguments and the user, that one is annoying). GHCi is capable of shelling out, so letting every browser tab on my computer talking to it is not ideal.
AFAIK Jupyter does not have any advanced features like dependency tracking between cells, or tracking variables, data, etc. So if you want Haskell in the browser, I recommend my approach, it is small, fast, the UI is configurable, and the whole process is hackable with hooks and transformations at any place.
It certainly can be inefficient depending on what you want to do, but loading files with functions into the scope of your GHCi session works quite well for quick debugging. When cabal repl all necessary deps for the project get loaded and it just works.
Wow ! Great use of MicroHS. What is the performance difference between interpreted MicroHS and warm compiled Haskell for a practical program eg. Shellcheck or similar ?
When I was toying with Haskell I was unable to get GHCi to interpret multiline definitions (Haskell is declarative, which means you don't make commands, but you declare commands which then get executed).
Jupyter+conda/anaconda is almost always not installable and broken for most of its kernels (it was for Haskell), so I ended up piping GHCi to a websocket server that I found on GitHub and a minimal HTML/JS frontend to talk to it: a reorderable list of textareas.
Then I added some security in the form of passing and verifying long random strings (via files, URL arguments and the user, that one is annoying). GHCi is capable of shelling out, so letting every browser tab on my computer talking to it is not ideal.
AFAIK Jupyter does not have any advanced features like dependency tracking between cells, or tracking variables, data, etc. So if you want Haskell in the browser, I recommend my approach, it is small, fast, the UI is configurable, and the whole process is hackable with hooks and transformations at any place.
It certainly can be inefficient depending on what you want to do, but loading files with functions into the scope of your GHCi session works quite well for quick debugging. When cabal repl all necessary deps for the project get loaded and it just works.
https://discourse.haskell.org/t/a-lighter-weight-alternative... talks about workarounds for multiline definitions
Wow ! Great use of MicroHS. What is the performance difference between interpreted MicroHS and warm compiled Haskell for a practical program eg. Shellcheck or similar ?
The author of Xeus-Haskell is here. Ask me anything.
you can/should post that in the jupyter zulip chat.