Re: [Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?

On Wed, Jun 5, 2013 at 3:56 PM, Roman Cheplyaka wrote:

* 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?

Pretty close. For anyone who wants to use hsc2hs in this way, the first step is to create a wrapper script to handle the arguments appropriately (otherwise the output doesn't go to the proper location)

file ghc_hsc2hs.sh #!/bin/sh hsc2hs $2 -o $3

Put the wrapper in your path, and add {-# OPTIONS_GHC -F -pgmF ghc_hsc2hs.sh #-} to the top of the source file. The source file must have a .hs extension for ghci to load it, but hsc2hs will ignore that and process it anyway. With this you can load the file in ghci, and if you modify the file reloading in ghci will pick up the changes, so it works pretty nicely. There are a couple drawbacks though. First, this isn't good for distribution because other people won't have your wrapper script. Second, this preprocessor stage comes after CPP, which might impose some difficulties in certain cases. I can see this working well for internal projects etc. If hsc2hs (and other preprocessors) were distributed in a fashion suitable for use with -F, either directly or by providing a wrapper, I think this could become the preferred workflow. I'm not entirely pleased that a non-Haskell file gets a .hs extension, but c'est la vie. I think it would generally be useful if ghc's -F phase were to support non-Haskell files, but that's probably a bit more work than just distributing a pgmF-friendly hsc2hs.