[GHC] #9256: Support automatic derivation of an hs-boot file from an hs file

[GHC]

#9256: Support automatic derivation of an hs-boot file from an hs file
------------------------------------+-------------------------------------
       Reporter:  ezyang            |             Owner:  ezyang
           Type:  feature request   |            Status:  new
       Priority:  normal            |         Milestone:
      Component:  Compiler          |           Version:  7.8.2
       Keywords:  backpack          |  Operating System:  Unknown/Multiple
   Architecture:  Unknown/Multiple  |   Type of failure:  None/Unknown
     Difficulty:  Unknown           |         Test Case:
     Blocked By:                    |          Blocking:
Related Tickets:                    |
------------------------------------+-------------------------------------
 This is essentially augustss's proposal from ticket #1409:

 I would settle for a solution where I annotate those entities in a module
 that would go in the hs-boot file.  So instead of me having to go through
 the trouble of creating an extra file I could just say, e.g.,

 Replying to [comment:13 augustss]:
 > I would settle for a solution where I annotate those entities in a
 module that would go in the hs-boot file.  So instead of me having to go
 through the trouble of creating an extra file I could just say, e.g.,
 >
 > {{{
 > {-# MODULE_MUTUAL_RECURSION_BREAKER T, foo #-}
 > data T = ...
 > foo :: ...
 > foo = ...
 > }}}
 >
 > The values that have an annotation would have to have a type signature.

 This should be eminently doable. Here is a more fleshed out proposal.

 First, consider the definition of an hs-boot file in the absence of mutual
 recursion (i.e. no breakers are necessary). In this case, the hi-boot file
 for an hs file is precisely the hi file produced after ordinary renaming
 and typechecking of the module.

 As an optimization, we would like to avoid typechecking definitions if an
 explicit type signature is present (if the type signature is absent, we
 have no choice.) There are a few choices here: we can force users to give
 top-level declarations for all exported functions (so unconditionally
 error if something is missing, by filtering out the relevant value
 declarations from the source), or we can go ahead and do full typechecking
 when the signature is missing. (The former is probably the simplest.)

 Now, how to handle breakers? We need to avoid typechecking them, since
 their recursive dependence means that they would not type check properly.
 So we should also filter out their type signatures. (Furthermore, if we
 are inferring some signatures, we need to make sure that their definitions
 don't rely on any breakers. For this reason, it is probably simplest to
 just require explicit type signatures.)

 If the mechanism for specifying breakers is exclusionary (as opposed to an
 inclusionary method of saying what values are in the signature), there is
 an awkward problem of syntax for exporting only an abstract type: the
 logical choices mean the wrong thing (`T(..)` seem to imply the type is
 eliminated entirely, whereas `T` seems to imply that the type should be
 eliminated, but not eh constructors.)

 Summary:

 1. Require top-level signatures in hs to hs-boot files(?)
 2. Exclusionary or inclusionary signature pragma?
 3. Filter out value declarations and excluded files, then rename/typecheck
 as normal, producing hi-boot file

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9256>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler