[Haskell] Hierarchical module namespace extension not sufficiently flexible

Simon Peyton-Jones simonpj at microsoft.com
Tue Mar 8 09:36:13 EST 2005


| Well, as an author of the Hierarchical Modules addendum, and as a
| compiler maintainer, I am already reasonably convinced of the utility
| of this suggestion.  It does significantly alter the semantics
| of import/export, in a way that the original Hierarchical Modules
| addendum does not, but as Iavor pointed out, this is not necessarily
| a bad thing.
| 
| What we now need is a precise definition.  After that, contributions
| of code to implement it would also be welcome.  :-)

Simon and I agree.  If someone is willing to evolve a detailed design,
presumably based on the current Hierarchical Modules addendum, and that
design met with general consent, we'd implement it in GHC.  (Provided it
didn't require massive changes, which would probably form part of the
design criteria.)

My current design is sketched below, but I have not thought about it as
long as others have.

Simon


Syntax: Extend the export syntax to allow, as an export item,

	qualified module M [( ...items... )] [as N]


Examples:

  module P( qualified module Button ) where 
	import GTK.This.That.Button as Button

  module Q( 
      qualified module GTK.This.That.Button as Button
   ) where
	import GTK.This.That.Button
		
  module R( qualified module Q( f,g ) ) where
	f = ...; g = ...


Semantics.  The effect of an export item 'qualified module' is to
expose some qualified names as well a unqualified ones.  That is the
only way to expose qualified names.   

The rules on import are just as now.  For example

  import P		-- Exposes P.Button.new, Button.new
  import qualified P	-- Exposes P.Button.new
  import qualified P as MyP 	-- Exposes MyP.Button.new

That is, the names exposed by the exporter are imported with or without
an extra qualifier, depending on the form of the import.


More information about the Libraries mailing list