| ... | ... | @@ -61,7 +61,7 @@ I believe this would solve the same problems as the above proposal, but would be |
|
|
|
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 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).
|
|
|
|
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.
|
|
|
|
|
|
|
|
# Permit qualified exports
|
|
|
|
|
| ... | ... | |