[-- 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 --]
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.
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