Mark P Jones writes an interesting suggestion: ... > Hmm, ok, but perhaps you're worrying now about having to enumerate > a verbose list of language features at the top of each module you > write. Isn't that going to detract from readability? This is where > the module system wins big! Just define a new module that imports all > the features you need, and then allows you to access them by a single > name. For example, you could capture the second feature set above > in the following: > > module HackersDelight where > import Extensions.Language.Mdo > import Extensions.Records.Structs > import Extensions.Types.RankN > import Extensions.Types.Multiparam > > Now the only thing you have to write at the top of a module that > needs some or all of these features is: > > import HackersDelight ...
Neat! But maybe it is not always desirable to impose an extension on the client of a module, just because the module itself needs it. If extensions were a kind of entity that can be mentioned in export and import lists, we could write module HackersDelight(mdo,structs,rankN,multiparam) where import Extensions.Language(mdo) ... Now, familiar mechanisms can be used from the module system. In particular, we can encode Hal's example (all extensions except Template Haskell): import HackersDelight hiding (th) /M _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
