The issue is in "practically", using it console with a kernel has some limitations, in particular stdin/out are not tty as far as the kernel is concerned; which leads to some things that jupyter_console can't do (e.g. running !vim), while IPython can. Jupyter_console is also way more buggy that plain IPython.
It doesn't look like this works in the web browser or uses any of the Jupyter infrastructure at all. It seems like the UX is far better than IHaskell's Jupyter console integration though, which is fantastic.
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.
ptGHCi author here. IHaskell and ptGHCi are really quite different in goals and design.
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.
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.
how does typeBarEnabled and tab completion work? I have yet to find a solution in any editor that can do type under cursor for a trivial codebase and this, for me at least, is the most necessary tool for writing Haskell because of how crappy docs are usually
13 comments
[ 2.7 ms ] story [ 43.0 ms ] threadhttps://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.