On Tue, Jun 4, 2013 at 10:15 PM, Ivan Lazar Miljenovic wrote:

Isn't this done automatically when you have files with the .hsc extension?

No, it is not.

On Tue, Jun 4, 2013 at 8:45 PM, John Lato wrote:

On Wed, Jun 5, 2013 at 10:15 AM, Ivan Lazar Miljenovic wrote:

...

On 5 June 2013 12:02, silly8888 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 intermediate step of calling hsc2hs? This would be exactly like the CPP extension. I don't have to call cpp manually. All I have to do is to add {-# LANGUAGE CPP #-} and then ghc will take care of the rest. This would also mean that there would be no need to have a separate file extension. Surely I must not be the first person to have that thought, so there must be a good reason why this hasn't happen yet, but what is it?

Isn't this done automatically when you have files with the .hsc extension?

cabal handles this transparently, but not ghc. It's frustrating when you want to develop a project with ghci.

I don't think it's a good idea to merge hsc2hs syntax into Haskell files. In particular, it's often useful to inspect the intermediate .hs file produced by hsc2hs during development or debugging. Also it would complicate ghc's parser, etc...

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 `ghci` command for cabal? Or does the automatic requirement really need to be part of ghc to work the way you want? (BTW, cabal-dev does have a `ghci` command, but I haven't tested to see if it does the hsc -> hs conversion.) Jason

* Jason Dagit [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 `ghci` command for cabal? Or does the automatic requirement really need to be part of ghc to work the way you want?

(BTW, cabal-dev does have a `ghci` command, but I haven't tested to see if it does the hsc -> hs conversion.)

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 it in ghci, you'd expect to load the updated version — yet cabal hasn't even been called since 'cabal ghci', and have had no chance to re-generate the hs file. To answer the subject question — hsc2hs is not a single preprocessor available. There are also c2hs and greencard, and maybe something else. It is (or, at least, was) not clear which one should be generally preferred. Perhaps by now hsc2hs is a clear winner — I don't know. Another option is to add a generic preprocessor option to GHC, something like -pgmX cmd. Then, for hsc2hs one would write something like {-# OPTIONS_GHC -pgmX hsc2hs #-} This is a better option, IMO. Roman

* Ivan Lazar Miljenovic [2013-06-05 17:47:40+1000]

On 5 June 2013 17:34, Roman Cheplyaka wrote:

...

* Jason Dagit [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 `ghci` command for cabal? Or does the automatic requirement really need to be part of ghc to work the way you want?

(BTW, cabal-dev does have a `ghci` command, but I haven't tested to see if it does the hsc -> hs conversion.)

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 it in ghci, you'd expect to load the updated version — yet cabal hasn't even been called since 'cabal ghci', and have had no chance to re-generate the hs file.

To answer the subject question — hsc2hs is not a single preprocessor available. There are also c2hs and greencard, and maybe something else. It is (or, at least, was) not clear which one should be generally preferred. Perhaps by now hsc2hs is a clear winner — I don't know.

Another option is to add a generic preprocessor option to GHC, something like -pgmX cmd. Then, for hsc2hs one would write something like

{-# OPTIONS_GHC -pgmX hsc2hs #-}

Isn't this what -pgmF is for?http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/options-phases.html#r...

{-# OPTIONS_GHC -F -pgmF hsc2hs #-}

Indeed! I should've read the whole section. Problem solved, then? Roman

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 it in ghci, you'd expect to load the updated version — yet cabal hasn't even been called since 'cabal ghci', and have had no chance to re-generate the hs file.

Maybe ghci could be changed to call some kind of hook everytime a file is called, and cabal could then provide an implementation for this hook that regenerates the files if necessary? Maybe this is even possible today using: :def r somethingCleverHere A quick test shows some minor problems, like :def r (const (return ":r")) :r looping. But maybe this could be figured out. Tillmann

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 without either adding hooks into ghci or wrapping stdin. As Roman points out, if you use :r in ghci, cabal-ghci wouldn't pick up changes in the source file. Using ghc's support for custom preprocessors seems like a very straightforward solution: it already exists, can be used today, and isn't tied to hsc2hs. Not that this should stop anyone from working on cabal-ghci of course. On Thu, Jun 6, 2013 at 11:43 AM, Jeremy Shaw wrote:

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 interest in doing anything more. Let's face it -- working on the FFI is just not that exciting :)

So, basically, we are stuck with stuff that is 'good enough' but no so great that we want to make it official.

We can bind to C fairly easily, but for C++, Python, Ruby, Javascript, Java, etc, we have never really made much headway.

I think the efforts to make cabal-ghci work nicely could really be the best solution for now. That is more extensible, and makes it easy to solve the problem you actually care about (being able to easily load/compile .hs files) with out giving priority to any particular FFI system.

- jeremy

On Tue, Jun 4, 2013 at 9:02 PM, silly8888 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 intermediate step of calling hsc2hs? This would be exactly like the CPP extension. I don't have to call cpp manually. All I have to do is to add {-# LANGUAGE CPP #-} and then ghc will take care of the rest. This would also mean that there would be no need to have a separate file extension. Surely I must not be the first person to have that thought, so there must be a good reason why this hasn't happen yet, but what is it?

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe