* Bug: Babel: haskell code evaluation inconsistency [7.7 (release_7.7.160.g3e33)]
@ 2011-08-19 22:38 Major A
2011-08-21 18:24 ` Eric Schulte
0 siblings, 1 reply; 4+ messages in thread
From: Major A @ 2011-08-19 22:38 UTC (permalink / raw)
To: emacs-orgmode
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))
)
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: Bug: Babel: haskell code evaluation inconsistency [7.7 (release_7.7.160.g3e33)]
2011-08-19 22:38 Bug: Babel: haskell code evaluation inconsistency [7.7 (release_7.7.160.g3e33)] Major A
@ 2011-08-21 18:24 ` Eric Schulte
2011-08-23 8:56 ` András Major
0 siblings, 1 reply; 4+ messages in thread
From: Eric Schulte @ 2011-08-21 18:24 UTC (permalink / raw)
To: Major A; +Cc: emacs-orgmode
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/
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: Bug: Babel: haskell code evaluation inconsistency [7.7 (release_7.7.160.g3e33)]
2011-08-21 18:24 ` Eric Schulte
@ 2011-08-23 8:56 ` András Major
2011-08-23 14:20 ` Eric Schulte
0 siblings, 1 reply; 4+ messages in thread
From: András Major @ 2011-08-23 8:56 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Bug: Babel: haskell code evaluation inconsistency [7.7 (release_7.7.160.g3e33)]
2011-08-23 8:56 ` András Major
@ 2011-08-23 14:20 ` Eric Schulte
0 siblings, 0 replies; 4+ messages in thread
From: Eric Schulte @ 2011-08-23 14:20 UTC (permalink / raw)
To: András Major; +Cc: emacs-orgmode
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/
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-08-23 14:39 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-19 22:38 Bug: Babel: haskell code evaluation inconsistency [7.7 (release_7.7.160.g3e33)] Major A
2011-08-21 18:24 ` Eric Schulte
2011-08-23 8:56 ` András Major
2011-08-23 14:20 ` Eric Schulte
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).