Haskell Interactive Notebook

:notebook: Haskell Notebook for VS Code — Seeking Community Feedback

What I’m building

A lightweight VS Code extension for interactive Haskell notebooks (`.ihsnb` → i for interactive | hs for haskell | nb for notebook) — *no Jupyter, no Python, no ZeroMQ*. Just GHCi, native VS Code APIs, and a clean workflow for literate Haskell.

Tech stack

  • TypeScript + VS Code Extension API using Notebook API

  • GHCi (`–interactive`) for evaluation

  • Custom parser for GHCi output

  • Markdown + code cells, persistent outputs, `:t` history

Community help would be amazing

:small_blue_diamond: Autocompletion: Implement native completions via `:complete`

:small_blue_diamond: HLS integration: Hover types, diagnostics, go-to-definition inside cells

:small_blue_diamond: State management: Isolate or reset context per cell

:small_blue_diamond: Testing & docs: Expand test coverage and contributor guides

If you’ve worked with GHCi internals, LSP, or VS Code extension dev — your insights would accelerate this project significantly. Even small feedback on UX or architecture is invaluable.

:link: Repo: GitHub - LARM-TECHs/haskell-notebook-vscode · GitHub

:folded_hands: Open to PRs, issues, and ideas. Let’s make interactive Haskell simpler. :crab:

:warning: Compatibility Note: This extension has currently only been tested with Haskell Platform 8.6.5, chosen for its straightforward installation process on Windows. Feedback, testing reports, and compatibility fixes for newer GHC versions or other operating systems are highly welcome!

How does this compare to IHaskell? Sure, this doesn’t use Jupyter, but it’s not obvious to me why that is a good thing. I’m also curious if there are any other advantages to your extension.

This seems like the bad kind of vibe coded project but I think there is merit to having a language specific notebook. Python has Marimo, Julia has Pluto. You have tighter integration with the language’s grammar do to things like reactivity. Also iHaskell specifically is hard to maintain well across platforms. De-jupytering a project seems like a good maintenance move.

Haven’t tried this notebook yet but I’ll give it a spin. Might be some good ideas in there.

Right now, I think Haskell’s portability is killing it. I’m stuck on GHCi 8.6.5 due to the end of Windows support, which is a shame. IHaskell is an excellent project, but it adds more complications due to dependencies. The goal is to keep it simple and decoupled—coupling only what’s necessary.

Any help, ideas, or future plans are more than welcome. I’d also love to see this idea spread and grow within the Haskell community.

That’s a fair point! The main reason I built this was to lower the barrier for learning Haskell.

With this extension, you can focus 100% on Haskell itself — no need to wrestle with Jupyter kernels, Python dependencies, ZeroMQ, or environment setup. Just install the extension, make sure `ghci` is in your PATH, and start writing code.

Just use WSL and you should be fine.

Is Windows not supported for ghci (anymore)? I have missed that.

It is, but it’s more complicated than just running an .exe file and choosing where to install it.