From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric Schulte" Subject: Re: Bugs in ob-haskell Date: Tue, 23 Nov 2010 07:49:16 -0700 Message-ID: <87d3pwnlhv.fsf@gmail.com> References: <87tyjaesql.wl%greenrd@greenrd.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from [140.186.70.92] (port=58002 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PKuBU-0000wy-Ck for emacs-orgmode@gnu.org; Tue, 23 Nov 2010 09:49:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PKuBT-00025b-4g for emacs-orgmode@gnu.org; Tue, 23 Nov 2010 09:49:28 -0500 Received: from mail-vw0-f41.google.com ([209.85.212.41]:53964) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PKuBT-00025S-02 for emacs-orgmode@gnu.org; Tue, 23 Nov 2010 09:49:27 -0500 Received: by vws10 with SMTP id 10so4289300vws.0 for ; Tue, 23 Nov 2010 06:49:26 -0800 (PST) In-Reply-To: <87tyjaesql.wl%greenrd@greenrd.org> (Robin Green's message of "Sun, 21 Nov 2010 13:00:50 +0000") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Robin Green Cc: Dan Davison , emacs-orgmode@gnu.org Hi Robin, Robin Green 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