Re: [O] Bug: Babel: haskell code evaluation inconsistency [7.7 (release_7.7.160.g3e33)]
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: [O] Bug: Babel: haskell code evaluation inconsistency [7.7 (release_7.7.160.g3e33)]
András Major andras.g.ma...@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/
Re: [O] Bug: Babel: haskell code evaluation inconsistency [7.7 (release_7.7.160.g3e33)]
Major A andras.g.ma...@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)
[O] Bug: Babel: haskell code evaluation inconsistency [7.7 (release_7.7.160.g3e33)]
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)) )
