Syntax extensions (was: RE: The Future of Haskell discussion at the Haskell Workshop)

[Magnus Carlsson]

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