Bug: Babel: haskell code evaluation inconsistency [7.7 (release_7.7.160.g3e33)]

Bug: Babel: haskell code evaluation inconsistency [7.7 (release_7.7.160.g3e33)]

[Major A]

Hi again,

I want to use haskell code blocks in order to evaluate them.  The
problem is that, depending on what haskell interpreters are installed
on the computer, Babel will call a different interpreter to evaluate
the code with.  Also, the haskell interpreter interface appears to be
highly stateful and unreliable.

Here's an example -- ghc6 is installed, but not hugs:

#+begin_src haskell :results output
  import System.IO
  openFile "doesNotExist.ppt" ReadMode
#+end_src

#+results:
: Loading package ghc-prim ... linking ... done.
: Loading package integer-gmp ... linking ... done.
: Loading package base ... linking ... done.

The interesting thing is that this output only occurs on the first run
of the code -- if I hit C-cC-c again, the #+results: section will be
empty.

Now the same source, with hugs installed in addition to ghc6 -- the
source block is the same, but the output is very different:

#+results:
: Type :? for help
: ERROR - Syntax error in expression (unexpected keyword "import")

Again, if I press C-cC-c again, the first line of output ("Type :? for
help") is no longer present.

This is what I suggest:

- Do away with "haskell" as the keyword for haskell code blocks, just
  like graphviz blocks use "dot" instead of simply "graphviz".

- Introduce new keywords -- I propose at least "runghc", "ghci", and
  "hugs".  This is important since there are significant source-level
  differences (see above) between hugs and ghc and even between the
  compiler and interpreter from the same project (ghc and ghci).
  Without these, the progammer will never be able to predict how the
  code is evaluated and which compiler or interpreter they must code
  for.

- Make sure the incorporation of the output or the value is done
  correctly (also see my previous bug report for this).

Enough for today,

  András



Emacs  : GNU Emacs 23.3.1 (i486-pc-linux-gnu, GTK+ Version 2.24.3)
 of 2011-04-10 on raven, modified by Debian
Package: Org-mode version 7.7 (release_7.7.160.g3e33)

current state:
==============
(setq
 org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-vars)
 org-speed-command-hook '(org-speed-command-default-hook org-babel-speed-command-hook)
 org-babel-load-languages '((asymptote . t) (ditaa . t) (dot . t) (gnuplot . t) (haskell . t) (latex . t) (octave . t)
 			  	           (R . t) (ruby . t) (scheme . t) (sh . t))
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-babel-tangle-lang-exts '(("ruby" . "rb") ("latex" . "tex") ("haskell" . "hs") ("asymptote" . "asy")
 			    	            ("emacs-lisp" . "el"))
 org-export-blocks-postblock-hook '(org-exp-res/src-name-cleanup)
 org-export-latex-format-toc-function 'org-export-latex-format-toc-default
 org-tab-first-hook '(org-hide-block-toggle-maybe org-src-native-tab-command-maybe org-babel-hide-result-toggle-maybe)
 org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-configure-edit-buffer)
 org-confirm-shell-link-function 'yes-or-no-p
 org-export-first-hook '(org-beamer-initialize-open-trackers)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-blank-before-new-entry nil
 org-babel-pre-tangle-hook '(save-buffer)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers org-cycle-show-empty-lines
 		  org-optimize-window-after-visibility-change)
 org-export-preprocess-before-normalizing-links-hook '(org-remove-file-link-modifiers)
 org-mode-hook '(#[nil "\300\301\302\303\304$\207" [org-add-hook change-major-mode-hook org-show-block-all append local]
 	          5]
			 #[nil "\300\301\302\303\304$\207"
			          [org-add-hook change-major-mode-hook org-babel-show-result-all append local] 5]
				  		 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point org-babel-execute-safely-maybe)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-export-interblocks '((lob org-babel-exp-lob-one-liners) (src org-babel-exp-inline-src-blocks))
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-occur-hook '(org-first-headline-recenter)
 org-from-is-user-regexp nil
 org-export-preprocess-before-selecting-backend-code-hook '(org-beamer-select-beamer-code)
 org-confirm-babel-evaluate nil
 org-export-latex-final-hook '(org-beamer-amend-header org-beamer-fix-toc org-beamer-auto-fragile-frames
 			     			              org-beamer-place-default-actions-for-lists)
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-export-blocks '((src org-babel-exp-src-block nil) (comment org-export-blocks-format-comment t)
 		        (ditaa org-export-blocks-format-ditaa nil) (dot org-export-blocks-format-dot nil))
 )
 

Re: Bug: Babel: haskell code evaluation inconsistency [7.7 (release_7.7.160.g3e33)]

[Eric Schulte]

Major A <andras.g.major@gmail.com> writes:

> Hi again,
>
> I want to use haskell code blocks in order to evaluate them.  The
> problem is that, depending on what haskell interpreters are installed
> on the computer, Babel will call a different interpreter to evaluate
> the code with.  Also, the haskell interpreter interface appears to be
> highly stateful and unreliable.
>

Currently inf-haskell is used for all evaluation, so Babel inherits both
its functionality and its weaknesses.  It seems that it would be
worthwhile to add non-session evaluation to haskell, and possibly a way
to specify which engine (hugs or ghci) is used in interactive
evaluation, presumably inf-haskell exports some way to make this
specification.

I personally don't have time to make these changes right now, but I'd be
happy to provide guidance and answer questions to anyone who wanted to
try to submit a patch.  Also, there are a number of files which can
serve as examples of how to compile and execute code with Babel e.g.,
ob-java.el and ob-C.el.

>
> Here's an example -- ghc6 is installed, but not hugs:
>
> #+begin_src haskell :results output
>   import System.IO
>   openFile "doesNotExist.ppt" ReadMode
> #+end_src
>
> #+results:
> : Loading package ghc-prim ... linking ... done.
> : Loading package integer-gmp ... linking ... done.
> : Loading package base ... linking ... done.
>
> The interesting thing is that this output only occurs on the first run
> of the code -- if I hit C-cC-c again, the #+results: section will be
> empty.
>
> Now the same source, with hugs installed in addition to ghc6 -- the
> source block is the same, but the output is very different:
>
> #+results:
> : Type :? for help
> : ERROR - Syntax error in expression (unexpected keyword "import")
>
> Again, if I press C-cC-c again, the first line of output ("Type :? for
> help") is no longer present.
>
> This is what I suggest:
>
> - Do away with "haskell" as the keyword for haskell code blocks, just
>   like graphviz blocks use "dot" instead of simply "graphviz".
>
> - Introduce new keywords -- I propose at least "runghc", "ghci", and
>   "hugs".  This is important since there are significant source-level
>   differences (see above) between hugs and ghc and even between the
>   compiler and interpreter from the same project (ghc and ghci).
>   Without these, the progammer will never be able to predict how the
>   code is evaluated and which compiler or interpreter they must code
>   for.
>
> - Make sure the incorporation of the output or the value is done
>   correctly (also see my previous bug report for this).
>

I would prefer to keep haskell as the source block type if only so that
the blocks are fontified with haskell-mode.  However something like an
:engine or :compiler keyword could be used to specify ghc or hugs.  The
other suggested changes seem like good ideas.

Best -- Eric

>
> Enough for today,
>
>   András
>
>
>
> Emacs  : GNU Emacs 23.3.1 (i486-pc-linux-gnu, GTK+ Version 2.24.3)
>  of 2011-04-10 on raven, modified by Debian
> Package: Org-mode version 7.7 (release_7.7.160.g3e33)
>
> current state:
> ==============
> (setq
>  org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-vars)
>  org-speed-command-hook '(org-speed-command-default-hook org-babel-speed-command-hook)
>  org-babel-load-languages '((asymptote . t) (ditaa . t) (dot . t) (gnuplot . t) (haskell . t) (latex . t) (octave . t)
>  			  	           (R . t) (ruby . t) (scheme . t) (sh . t))
>  org-metaup-hook '(org-babel-load-in-session-maybe)
>  org-after-todo-state-change-hook '(org-clock-out-if-current)
>  org-babel-tangle-lang-exts '(("ruby" . "rb") ("latex" . "tex") ("haskell" . "hs") ("asymptote" . "asy")
>  			    	            ("emacs-lisp" . "el"))
>  org-export-blocks-postblock-hook '(org-exp-res/src-name-cleanup)
>  org-export-latex-format-toc-function 'org-export-latex-format-toc-default
>  org-tab-first-hook '(org-hide-block-toggle-maybe org-src-native-tab-command-maybe org-babel-hide-result-toggle-maybe)
>  org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-configure-edit-buffer)
>  org-confirm-shell-link-function 'yes-or-no-p
>  org-export-first-hook '(org-beamer-initialize-open-trackers)
>  org-agenda-before-write-hook '(org-agenda-add-entry-text)
>  org-blank-before-new-entry nil
>  org-babel-pre-tangle-hook '(save-buffer)
>  org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers org-cycle-show-empty-lines
>  		  org-optimize-window-after-visibility-change)
>  org-export-preprocess-before-normalizing-links-hook '(org-remove-file-link-modifiers)
>  org-mode-hook '(#[nil "\300\301\302\303\304$\207" [org-add-hook change-major-mode-hook org-show-block-all append local]
>  	          5]
> 			 #[nil "\300\301\302\303\304$\207"
> 			          [org-add-hook change-major-mode-hook org-babel-show-result-all append local] 5]
> 				  		 org-babel-result-hide-spec org-babel-hide-all-hashes)
>  org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point org-babel-execute-safely-maybe)
>  org-confirm-elisp-link-function 'yes-or-no-p
>  org-export-interblocks '((lob org-babel-exp-lob-one-liners) (src org-babel-exp-inline-src-blocks))
>  org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
>  org-occur-hook '(org-first-headline-recenter)
>  org-from-is-user-regexp nil
>  org-export-preprocess-before-selecting-backend-code-hook '(org-beamer-select-beamer-code)
>  org-confirm-babel-evaluate nil
>  org-export-latex-final-hook '(org-beamer-amend-header org-beamer-fix-toc org-beamer-auto-fragile-frames
>  			     			              org-beamer-place-default-actions-for-lists)
>  org-metadown-hook '(org-babel-pop-to-session-maybe)
>  org-export-blocks '((src org-babel-exp-src-block nil) (comment org-export-blocks-format-comment t)
>  		        (ditaa org-export-blocks-format-ditaa nil) (dot org-export-blocks-format-dot nil))
>  )
>  
>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: Bug: Babel: haskell code evaluation inconsistency [7.7 (release_7.7.160.g3e33)]

[András Major]

Hi Eric,

> I personally don't have time to make these changes right now, but I'd be
> happy to provide guidance and answer questions to anyone who wanted to
> try to submit a patch.  Also, there are a number of files which can
> serve as examples of how to compile and execute code with Babel e.g.,
> ob-java.el and ob-C.el.

That's what I suspected judging from the behaviour I've seen.  Is
anyone else interested in such work?  I don't have much time either,
in particular I'm not sufficiently familiar with emacs and Lisp to do
something useful quickly.

> I would prefer to keep haskell as the source block type if only so that
> the blocks are fontified with haskell-mode.  However something like an
> :engine or :compiler keyword could be used to specify ghc or hugs.

Good idea, but specifying ghc is ambiguous: it'll have to be either
ghci, runghc/runhaskell, oder hugs, or maybe some other
interpreter/compiler someone else would like to use (nhc98, etc.,
there a quite a few).  At least the three options I listed all have
incompatibilities in even the simplest use cases, owing to the
peculiarities of Haskell as a pure, declarative language.

Also, using runghc would require the code block to be tangled first
into a temporary file.  Is that easily done in babel?

  András

Re: Bug: Babel: haskell code evaluation inconsistency [7.7 (release_7.7.160.g3e33)]

[Eric Schulte]

András Major <andras.g.major@gmail.com> writes:

> Hi Eric,
>
>> I personally don't have time to make these changes right now, but I'd be
>> happy to provide guidance and answer questions to anyone who wanted to
>> try to submit a patch.  Also, there are a number of files which can
>> serve as examples of how to compile and execute code with Babel e.g.,
>> ob-java.el and ob-C.el.
>
> That's what I suspected judging from the behaviour I've seen.  Is
> anyone else interested in such work?  I don't have much time either,
> in particular I'm not sufficiently familiar with emacs and Lisp to do
> something useful quickly.
>
>> I would prefer to keep haskell as the source block type if only so that
>> the blocks are fontified with haskell-mode.  However something like an
>> :engine or :compiler keyword could be used to specify ghc or hugs.
>
> Good idea, but specifying ghc is ambiguous: it'll have to be either
> ghci, runghc/runhaskell, oder hugs, or maybe some other
> interpreter/compiler someone else would like to use (nhc98, etc.,
> there a quite a few).  At least the three options I listed all have
> incompatibilities in even the simplest use cases, owing to the
> peculiarities of Haskell as a pure, declarative language.
>

A more open-ended :compiler or :interpreter header argument accepting
ghc, rungch, hugs and nhc98 among others, sounds like a good idea.

>
> Also, using runghc would require the code block to be tangled first
> into a temporary file.  Is that easily done in babel?
>

Very easily, see ob-java.el.  Adopting the compile-then-run
functionality from there should not be a large task.

Best -- Eric

>
>   András
>
>
>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/