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

[John Lato]

On Wed, Jun 5, 2013 at 3:56 PM, Roman Cheplyaka <roma at ro-che.info> wrote:

> * Ivan Lazar Miljenovic <ivan.miljenovic at gmail.com> [2013-06-05
> 17:47:40+1000]
> > On 5 June 2013 17:34, Roman Cheplyaka <roma at ro-che.info> wrote:
> > > * Jason Dagit <dagitj at 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 `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#replacing-phases
> >
> > {-# 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130606/7a59b17c/attachment.htm>