From: "Eric Schulte" <schulte.eric@gmail.com>
To: Robin Green <greenrd@greenrd.org>
Cc: Dan Davison <davison@stats.ox.ac.uk>, emacs-orgmode@gnu.org
Subject: Re: Bugs in ob-haskell
Date: Tue, 23 Nov 2010 07:49:16 -0700 [thread overview]
Message-ID: <87d3pwnlhv.fsf@gmail.com> (raw)
In-Reply-To: <87tyjaesql.wl%greenrd@greenrd.org> (Robin Green's message of "Sun, 21 Nov 2010 13:00:50 +0000")
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
prev parent reply other threads:[~2010-11-23 14:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-21 13:00 Bugs in ob-haskell Robin Green
2010-11-23 14:49 ` Eric Schulte [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d3pwnlhv.fsf@gmail.com \
--to=schulte.eric@gmail.com \
--cc=davison@stats.ox.ac.uk \
--cc=emacs-orgmode@gnu.org \
--cc=greenrd@greenrd.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).