* Jason Dagit dag...@gmail.com [2013-06-04 21:00:25-0700]
My preferred solution would be to have ghc/ghci automatically run hsc2hs
(support c2hs also?) when necessary. But so long as it's handled
automatically, I wouldn't be particularly bothered by the implementation.
How about having a
On 5 June 2013 17:34, Roman Cheplyaka r...@ro-che.info wrote:
* Jason Dagit dag...@gmail.com [2013-06-04 21:00:25-0700]
My preferred solution would be to have ghc/ghci automatically run hsc2hs
(support c2hs also?) when necessary. But so long as it's handled
automatically, I wouldn't be
* Ivan Lazar Miljenovic ivan.miljeno...@gmail.com [2013-06-05 17:47:40+1000]
On 5 June 2013 17:34, Roman Cheplyaka r...@ro-che.info wrote:
* Jason Dagit dag...@gmail.com [2013-06-04 21:00:25-0700]
My preferred solution would be to have ghc/ghci automatically run hsc2hs
(support c2hs
Hi,
Roman Cheplyaka wrote:
My preferred solution would be to have ghc/ghci automatically run hsc2hs
[...] when necessary.
How about having a `ghci` command for cabal?
I don't think cabal can provide that. Let's say you're inside a 'cabal
ghci' session. If you modify the hsc file and reload
On Wed, Jun 5, 2013 at 3:56 PM, Roman Cheplyaka r...@ro-che.info wrote:
* Ivan Lazar Miljenovic ivan.miljeno...@gmail.com [2013-06-05
17:47:40+1000]
On 5 June 2013 17:34, Roman Cheplyaka r...@ro-che.info wrote:
* Jason Dagit dag...@gmail.com [2013-06-04 21:00:25-0700]
My preferred
While hsc2hs is a popular FFI preprocessor, it is not the only one.
There is also greencard and a few others.
While hsc2hs can usually get the job done -- it's not clear that it is
really the best choice. I think the Haskell FFI got to the point that
it was 'just good enough' and then people lost
I agree that preprocessing code shouldn't be hsc2hs specific. I prefer
c2hs myself. But hsc2hs is distributed with ghc, which makes it as
official as a good many other parts of modern Haskell.
I also agree that making cabal-ghci work nicely would be ideal, but I don't
think it can be done
I was wondering today, why hasn't hsc2hs been merged with ghc so that
it would be possible to add a
{-# LANGUAGE ForeignFunctionInterface #-}
at the top of a source file and then load it with ghci or compile it,
without the intermediate step of calling hsc2hs? This would be exactly
like the CPP
On 5 June 2013 12:02, silly silly8...@gmail.com wrote:
I was wondering today, why hasn't hsc2hs been merged with ghc so that
it would be possible to add a
{-# LANGUAGE ForeignFunctionInterface #-}
at the top of a source file and then load it with ghci or compile it,
without the
On Tue, Jun 4, 2013 at 10:15 PM, Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com wrote:
Isn't this done automatically when you have files with the .hsc extension?
No, it is not.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
On Wed, Jun 5, 2013 at 10:15 AM, Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com wrote:
On 5 June 2013 12:02, silly silly8...@gmail.com wrote:
I was wondering today, why hasn't hsc2hs been merged with ghc so that
it would be possible to add a
{-# LANGUAGE ForeignFunctionInterface
On Tue, Jun 4, 2013 at 8:45 PM, John Lato jwl...@gmail.com wrote:
On Wed, Jun 5, 2013 at 10:15 AM, Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com wrote:
On 5 June 2013 12:02, silly silly8...@gmail.com wrote:
I was wondering today, why hasn't hsc2hs been merged with ghc so that
it
cabal-dev ghci does work with hsc2hs, but only because it doesn't interpret
your source. Rather, cabal-dev ghci loads ghci using the sandbox install
of your package, which is less useful for a variety of reasons.
Aside from that detail, I wouldn't gain any benefit from having this
feature built
13 matches
Mail list logo
