<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 5, 2013 at 3:56 PM, Roman Cheplyaka <span dir="ltr"><<a href="mailto:roma@ro-che.info" target="_blank">roma@ro-che.info</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">* Ivan Lazar Miljenovic <<a href="mailto:ivan.miljenovic@gmail.com">ivan.miljenovic@gmail.com</a>> [2013-06-05 17:47:40+1000]<br>
<div><div class="h5">> On 5 June 2013 17:34, Roman Cheplyaka <<a href="mailto:roma@ro-che.info">roma@ro-che.info</a>> wrote:<br>
> > * Jason Dagit <<a href="mailto:dagitj@gmail.com">dagitj@gmail.com</a>> [2013-06-04 21:00:25-0700]<br>
> >> > My preferred solution would be to have ghc/ghci automatically run hsc2hs<br>
> >> > (support c2hs also?) when necessary. But so long as it's handled<br>
> >> > automatically, I wouldn't be particularly bothered by the implementation.<br>
> >><br>
> >> How about having a `ghci` command for cabal? Or does the automatic<br>
> >> requirement really need to be part of ghc to work the way you want?<br>
> >><br>
> >> (BTW, cabal-dev does have a `ghci` command, but I haven't tested to<br>
> >> see if it does the hsc -> hs conversion.)<br>
> ><br>
> > I don't think cabal can provide that. Let's say you're inside a 'cabal<br>
> > ghci' session. If you modify the hsc file and reload it in ghci, you'd<br>
> > expect to load the updated version — yet cabal hasn't even been called<br>
> > since 'cabal ghci', and have had no chance to re-generate the hs file.<br>
> ><br>
> > To answer the subject question — hsc2hs is not a single preprocessor<br>
> > available. There are also c2hs and greencard, and maybe something else.<br>
> > It is (or, at least, was) not clear which one should be generally<br>
> > preferred. Perhaps by now hsc2hs is a clear winner — I don't know.<br>
> ><br>
> > Another option is to add a generic preprocessor option to GHC, something<br>
> > like -pgmX cmd. Then, for hsc2hs one would write something like<br>
> ><br>
> > {-# OPTIONS_GHC -pgmX hsc2hs #-}<br>
><br>
> Isn't this what -pgmF is<br>
> for?<a href="http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/options-phases.html#replacing-phases" target="_blank">http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/options-phases.html#replacing-phases</a><br>
><br>
> {-# OPTIONS_GHC -F -pgmF hsc2hs #-}<br>
<br>
</div></div>Indeed! I should've read the whole section.<br>
<br>
Problem solved, then?</blockquote><div><br></div><div style>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)</div>
<div style><br></div><div style>> file ghc_hsc2hs.sh</div><div style>> #!/bin/sh</div><div style>> hsc2hs $2 -o $3</div><div style><br></div><div style>Put the wrapper in your path, and add</div><div style>{-# OPTIONS_GHC -F -pgmF ghc_hsc2hs.sh #-}</div>
<div style><br></div><div style>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.</div><div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div></div>
</div></div>