[GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything)

[GHC]

#1409: Allow recursively dependent modules transparently (without .hs-boot or
anything)
------------------------------+---------------------------------------------
  Reporter:  Isaac Dupree     |          Owner:         
      Type:  feature request  |         Status:  new    
  Priority:  normal           |      Milestone:         
 Component:  Compiler         |        Version:  6.6.1  
  Severity:  normal           |       Keywords:         
Difficulty:  Unknown          |             Os:  Unknown
  Testcase:                   |   Architecture:  Unknown
------------------------------+---------------------------------------------
Essentially, compile strongly-connected sets of modules like single
 modules are compiled (they have to have the same default and monomorphism-
 restriction, so it is like compiling one module, after the module/import
 fixpoint and name resolution are done).

 This can increase the amount of recompilation necessary compared to using
 .hs-boot files, so it is probably desirable to still allow those.  Of
 course, manually keeping .hs-boot files and {-#SOURCE#-} pragmas around
 (and synchronized with the real code) is a nuisance (though informative if
 one cares about minimizing the amount of recursion).  I suspect that there
 can be situations where one level of export-subsets via .hs-boot files is
 not sufficient... (which would be one reason it wouldn't be easy to "just"
 treat a subset of each .hs file as its .hs-boot).

 When not using --make mode, ghc would have to find the minimal module
 cycles somehow, and put just one ".hi-boots" or ".his", and .o I think,
 file somewhere (next to an arbitrary one of the modules I guess) in order
 that the compilation isn't repeated pointlessly for each module.  And deal
 with which compiler flags are used.  Maybe better not to allow it without
 --make.

 In --make mode, such hackery should not be needed.  This might also help
 deal with (work around?) such existing bugs with recursive modules and
 --make: #930 , #1072 , #1133 .  The modules having different OPTIONS_GHC
 or LANGUAGE pragmas might still be tricky or impossible to accept,
 depending which ones they are and how much implementation effort it's
 worth investing in allowing that.  (Although, class instances being
 overlappable might be advantageous to have implemented a per-class not
 per-module specification anyway, for example, so pragmas that affect less
 than the whole module could be added more easily.)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1409>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
-------------- next part --------------
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs at haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs