Permit Signatures in Export Lists

There is a good case to be made for permitting the inclusion of function signatures in the export list of a module. People often write them there anyway in comments, but the comments are not checked against the implementation, so changes can go unnoticed. There is also a good software engineering principle that says you should specify your interfaces as fully as possible. Signatures in export lists should be considered equivalant to signatures specified in the module itself at the top level for all purposes. If there are signatures in both the interface and the implementation, they should be identical (not just unifiable).

If we /required/ signatures in export lists (and always required a full export list too), this would solve the recursive module problem for some compilers very simply. The export list would represent exactly the information currently contained in ghc's hs-boot files (and nhc98's hand-written .hi bootstrapping method). Other compilers such as jhc and helium have no problem with recursive modules as is. However, I do not yet propose that signatures be mandatory - just permitting them would already be a large and useful step.

Grammar changes

The export syntax changes trivially from

    export  -> qvar
            |  qtycon [ (..) | ( cname_1, ... , cname_n ) ]	(n>=0)
            |  qtycls [ (..) | ( var_1, ... , var_n ) ]		(n>=0)
            |  module modid

to

    export  -> qvar [ :: type ]
            |  qtycon [ (..) | ( cname_1, ... , cname_n ) ]	(n>=0)
            |  qtycls [ (..) | ( var_1, ... , var_n ) ]		(n>=0)
            |  module modid