#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.10.2          
    Severity:  normal            |   Resolution:                  
    Keywords:                    |   Difficulty:  Unknown         
    Testcase:                    |           Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |  
---------------------------------+------------------------------------------
Comment (by simonpj):

 "I absolutely hate it if I have to write a .hc-boot file" (I assume you
 mean hs-boot file).  I'm interested in identifying precisely what it is
 that you hate, lest we fix the wrong thing:

  * Do you hate writing the type signatures of the functions that the
 module exports?  (After all, most Haskell programmers do that routinely.)
  * Do you hate putting those type signatures in a physically different
 file?  That is would the hate be alleviated if the signatures were in the
 same file as the module implementation?
  * Or perhaps you hate something else?  Such as having to pick a place to
 cut the recursive loop at all?

 I'm interested in this because the ML community regards it as a ''major''
 virtue that module signatures and implementations are separate, so that
 you can
   * Import a module (via its signature) before you have written its
 implementation
   * Provide more than one implementation of a common signature, and
 thereby be confident that switching implementations will not cause errors.

 Being clear about goals will help the design.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1409#comment:22>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Reply via email to