4 ms·

There is already a Haskell kernel for IPython: https://github.com/gibiansky/IHaskell https://github.com/gibiansky/IHaskell How does this project differ in sco

by rkrzr 7y ago

There is already a Haskell kernel for IPython: https://github.com/gibiansky/IHaskell 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. )

timdiggerm 7y ago
And now there are two.
droelf 7y ago
Additionally running jupyter_console with this kernel, one should get practically the same thing.
- carreau 7y ago
  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.
vaibhavsagar 7y ago
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. (I currently help maintain IHaskell)
- ben509 7y ago
  > IMO the biggest issue with IHaskell is that it requires a correctly configured Python environment Ah, you reminded me that I need to put up a PR with some fixes...
rwarfield 7y ago
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.

by rkrzr 7y ago

timdiggerm 7y ago

And now there are two.

droelf 7y ago

Additionally running jupyter_console with this kernel, one should get practically the same thing.

carreau 7y ago
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.

vaibhavsagar 7y ago

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. (I currently help maintain IHaskell)

ben509 7y ago
> IMO the biggest issue with IHaskell is that it requires a correctly configured Python environment Ah, you reminded me that I need to put up a PR with some fixes...

rwarfield 7y ago

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.