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

[Eric Schulte <schulte.eric@gmail.com>]

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/