Bugs in ob-haskell

Bugs in ob-haskell

[Robin Green]

I've noticed a number of bugs in ob-haskell:

1. The first time I ran my code block, the results were given as something like:

Prelude> [[1], [2], [3]]

and of course, this isn't an org table, as it should be.

I don't think the "Prelude> " should have been there, and I suspect a race condition,
because after I immediately did C-c C-c again, the results changed to a table.

2. Looking at ob-haskell.el, it seems like Haskell strings are converted into text
by removing leading and trailing double quotes. However, if there are double quote
characters inside the string, they will be escaped with a backslash when printed,
and they will presumably need to be unescaped. (Haven't tested this though.)

3. Ordinary Haskell lists can't have values of different types inside them, at least
not without some sort of wrapper. But if you have a number and a string in your
table, ob-haskell will try to make an impossible list with a number and a string in
it. My preferred solution to this bug would be to force all list items to strings
(at least, if there are any strings at all in the input table or list).

4. What's worse is, if ob-haskell makes an error in setting your input variables,
like the error in the previous paragraph, and this is not the first run of that
code block and you haven't changed the variable names, the error arising from the
"let" command will simply be ignored silently by ob-haskell! The previous value
of the variable will be used instead. At least, that is what happens to me.

Regards,
-- 
Robin Green

Re: Bugs in ob-haskell

[Eric Schulte]

Hi Robin,

Robin Green <greenrd@greenrd.org> writes:

> I've noticed a number of bugs in ob-haskell:
>
> 1. The first time I ran my code block, the results were given as something like:
>
> Prelude> [[1], [2], [3]]
>
> and of course, this isn't an org table, as it should be.
>
> I don't think the "Prelude> " should have been there, and I suspect a
> race condition, because after I immediately did C-c C-c again, the
> results changed to a table.
>

Yes, the very first execution in a new session can sometimes lead to
such problems as the session warms up.

>
> 2. Looking at ob-haskell.el, it seems like Haskell strings are
> converted into text by removing leading and trailing double
> quotes. However, if there are double quote characters inside the
> string, they will be escaped with a backslash when printed, and they
> will presumably need to be unescaped. (Haven't tested this though.)
>

This problem (if there was one, it sounds as though you did not check)
is now fixed by a quoting fix applied to a number of languages including
Haskell.

>
> 3. Ordinary Haskell lists can't have values of different types inside
> them, at least not without some sort of wrapper. But if you have a
> number and a string in your table, ob-haskell will try to make an
> impossible list with a number and a string in it. My preferred
> solution to this bug would be to force all list items to strings (at
> least, if there are any strings at all in the input table or list).
>

I would disagree that this is a bug.  True, Haskell does not allow lists
of mixed types, so then the user shouldn't pass in lists of mixed types,
and if they do, Haskell will spit out a warning.  I find this behavior
more clear and straightforward than the proposed behavior of having
Babel automatically "fix" your list by converting all elements to
strings.  The user can do that explicitly themselves using something
like the following (could be added to your LOB to make this process even
easier).

#+tblname: mixed-table
| 1 | first  |
| 2 | second |
| 3 | third  |
| 4 | fourth | 

#+source: rec-string-wrap
#+begin_src emacs-lisp :var data=mixed-table
  (defun rec-string-wrap (in)
    (if (listp in) (mapcar #'rec-string-wrap in) (format "%S" in)))
  (rec-string-wrap data)
#+end_src

#+begin_src haskell :var tbl=rec-string-wrap(data=mixed-table)
  map head tbl
#+end_src

#+results:
| 1 | 2 | 3 | 4 |

>
> 4. What's worse is, if ob-haskell makes an error in setting your input
> variables, like the error in the previous paragraph, and this is not
> the first run of that code block and you haven't changed the variable
> names, the error arising from the "let" command will simply be ignored
> silently by ob-haskell! The previous value of the variable will be
> used instead. At least, that is what happens to me.
>

This is an effect of how variables work in the interactive Haskell
session, previous values are not overwritten by erroneous assignment to
the same variable name.  Changing this behavior is beyond the scope of
the babel integration.  That said it would be great if the Haskell
integration allowed for executing code blocks using an external Haskell
process in stead of the interactive session, unfortunately this is
currently not implemented and would presumably require some simple
monadic wrapper to output results from the execution in a format which
could be captured and brought back into Emacs.

As always patches are welcome.

-- Eric