"S. Alexander Jacobson"
Simon,
Right now, a module name in an import declaration identifies a module specification, a module name in a module declaration identifies an implementation, and some "external mechanism" resolves specifications to implementations. The big issue on the table here is what exactly this "external mechanism" should be. I'll suggest some requirements:
1. It should require minimal work for a user to share an implementation.
Unfortunately, our existing module resolver mechanisms are severely inadequate here. Build-depends and -package both violate #1 because they both force users to create packages even to share standalone pure haskell modules.
That's not true. Of course a single standalone pure haskell module or a set of simple modules can just sit in your source tree or elsewhere on the search path, just as they always have. Also framing this as a "Cabal vs. Haskell" discussion where you claim that your opinion is the True Haskell Way is both unfair and annoying. A couple of point of clarity for anyone following this discussion: - Cabal doesn't require any changes or extensions to the Haskell language (it's not Cabal vs. Haskell!) - The packaging system pre-dates Cabal. Cabal was layered on top of the packaging system, and a newer, more robust packaging system was designed and implemented in GHC in order to support more. At this point, I hope no one is drawing information about Cabal from your posts. peace, isaac