ob-haskell

ob-haskell

[Lawrence Bottorff]

[-- Attachment #1: Type: text/plain, Size: 1871 bytes --]

I recently wimped out of trying to update ob-haskell as an official
maintainer, but I'd eventually like to get back to it -- *after *I get some
base understanding of what Haskell is (Zeno's paradox-land?) and how the
ghci works. Basically, the ghci is what it is -- tautological, but true.
And that means when ob-haskell does nothing but dump the contents of a
babel code block into ghci, it's no better than if the user had typed in
into the REPL line-by-line. A quick run-down:

:set +m supposedly alerts ghci that a multi-line expression is coming, will
come; but typically, it doesn't infer this very well.

Enclosing code in :{ ... :} is fairly good -- again you can type this in at
the REPL prompt and see how it works -- however, there are gotchas.

a plain block:

#+begin_src haskell
...code...
#+end_src

is okay when you only have a one-liner to evaluate. But again, ob-haskell
seems to do nothing but take the block contents and dump it to the ghci
REPL as though the user had typed it in line-by-line, Enter, Enter...

What would be nice is if a C-c C-c inside a block could somehow act as
though the ghci were being sent a regular  *.hs buffer in haskell-mode --
and that, of course, cumulatively. C-' creates a decent haskell-mode
environment, BTW, so some form of a babel block to haskell-mode connection
does exist....

So am I on the right track? It's obvious at this point raw dumps into the
REPL aren't optimal, i.e., are fraught. What is, e.g., geiser&Scheme doing
that ob-haskell isn't?

LB

PS: Eventually, I'll try to glean some hints from the Jupyter Haskell
<https://github.com/gibiansky/IHaskell> effort.

PPS: GHCI User's Guide
<https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html>
doesn't
really tell me anything other than yes, ob-haskell is raw-dumping into an
environment that isn't designed to play nice with babel.

[-- Attachment #2: Type: text/html, Size: 2243 bytes --]

Re: ob-haskell

[Ken Mankoff]

Hi Lawrence,

This isn't a method for official language support, but I've had success with entirely unsupported REPLs and ob-screen. A .screenrc can launch the REPL, and then Org ob-screen just sends each line to the buffer. It works OK for me.

  -k.

On 2021-01-02 at 13:44 -08, Lawrence Bottorff <borgauf@gmail.com> wrote...
> I recently wimped out of trying to update ob-haskell as an official
> maintainer, but I'd eventually like to get back to it -- *after *I get
> some base understanding of what Haskell is (Zeno's paradox-land?) and
> how the ghci works. Basically, the ghci is what it is -- tautological,
> but true. And that means when ob-haskell does nothing but dump the
> contents of a babel code block into ghci, it's no better than if the
> user had typed in into the REPL line-by-line. A quick run-down:
>
> :set +m supposedly alerts ghci that a multi-line expression is coming, will
> come; but typically, it doesn't infer this very well.
>
> Enclosing code in :{ ... :} is fairly good -- again you can type this in at
> the REPL prompt and see how it works -- however, there are gotchas.
>
> a plain block:
>
> #+begin_src haskell
> ...code...
> #+end_src
>
> is okay when you only have a one-liner to evaluate. But again, ob-haskell
> seems to do nothing but take the block contents and dump it to the ghci
> REPL as though the user had typed it in line-by-line, Enter, Enter...
>
> What would be nice is if a C-c C-c inside a block could somehow act as
> though the ghci were being sent a regular  *.hs buffer in haskell-mode --
> and that, of course, cumulatively. C-' creates a decent haskell-mode
> environment, BTW, so some form of a babel block to haskell-mode connection
> does exist....
>
> So am I on the right track? It's obvious at this point raw dumps into the
> REPL aren't optimal, i.e., are fraught. What is, e.g., geiser&Scheme doing
> that ob-haskell isn't?
>
> LB
>
> PS: Eventually, I'll try to glean some hints from the Jupyter Haskell
> <https://github.com/gibiansky/IHaskell> effort.
>
> PPS: GHCI User's Guide
> <https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html>
> doesn't
> really tell me anything other than yes, ob-haskell is raw-dumping into an
> environment that isn't designed to play nice with babel.

Re: ob-haskell

[Leo]

Lawrence Bottorff <borgauf@gmail.com> writes:

> Enclosing code in :{ ... :} is fairly good -- again you can type this in at
> the REPL prompt and see how it works -- however, there are gotchas.
>

I don't think I understand what the problem is with :{ ... :}. Doing
this manually has worked pretty well for me.

>
> What would be nice is if a C-c C-c inside a block could somehow act as
> though the ghci were being sent a regular  *.hs buffer in haskell-mode --
> and that, of course, cumulatively. C-' creates a decent haskell-mode
> environment, BTW, so some form of a babel block to haskell-mode connection
> does exist....
>

This makes a lot of sense in many cases. One case that I think it might
be suboptimal in is when I have a heavy computation that generates
some data. Then I would want to try to do a bunch of things to that data
which means that reloading everything would be suboptimal.

I don't know how other babel plugins work, but the way I enjoy working
with ghci the most is to load in a file to ghci and then test a bunch of
expressions in the repl. Maybe ob-haskell could work like this as well,
with one type of block that loads the code as a file and another block
that just sends the code to the repl. There are some problems here that
needs to be sorted out though. For example should each block of the
former type be loaded in its own module or should all of the code blocks
be loaded in the same module? 


/A sporadic user of ob-haskell