High-Powered REPL for Haskell, Inspired by IPython
github.com
github.com
https://github.com/gibiansky/IHaskell
How does this project differ in scope/design goals?
(This project uses a different approach to implement essentially the same thing:
> It is implemented as a wrapper around GHCi based on Python's prompt-toolkit library and heavily inspired by IPython. )
IMO the biggest issue with IHaskell is that it requires a correctly configured Python environment (in addition to a correctly configured Haskell environment), which this also does, so I don't think this is a substantive improvement.
(I currently help maintain IHaskell)
Ah, you reminded me that I need to put up a PR with some fixes...
ptGHCi is a wrapper around GHCi. In fact, it runs GHCi as a subprocess. That means almost all GHCi features are supported out of the box. No matter you were using GHCi before, you can continue to do so -- whether standalone or under stack or cabal. ptGHCi doesn't care what GHC version you're using -- you can build ptGHCi with one version and use it to develop a project under another version. And .ghci configuration files are mostly respected (though there are some exceptions, such as the prompt, which ptGHCi takes over).
IHaskell is all about Jupyter and its ecosystem. More specifically, I think it's safe to say (though I don't want to put words in the authors' mouths) that the main use case is for creating HTML-based notebooks with rich media output (diagrams, graphs, etc). IHaskell doesn't use GHCi at all and only supports a subset of GHCi commands. While you could configure IHaskell to run in a console, I don't think you would gain much by doing so vs. vanilla GHCi.
At some point in the future, I hope to add support for using ptGHCi as a Jupyter kernel -- mainly because it should be easy to do so. Compared to IHaskell, ptGHCi in Jupyter would give you the full power of GHCi, at the expense of (probably) losing the rich media capabilities of IHaskell. But this isn't a major goal of ptGHCi.
- https://blog.jupyter.org/a-new-python-kernel-for-jupyter-fcd...
- https://github.com/QuantStack/xeus
One day, hopefully, language-independent part of Jupyter will be rewritten completely in Rust (backend) and WebAssembly (frontend), to achieve the portability, better safety guarantees, and speed.