[Haskell-cafe] Design your modules for qualified import

[Henning Thielemann]

On Sat, 14 Jun 2008, Isaac Dupree wrote:

> yeah, we could come up with a syntax. one that gives privileged meaning to 
> hierarchy.  If used according to "design your modules for qualified import", 
> it would still allow fairly easy use and looking up function uses.
>
> import Graphics.UI.GTK (import qualified Button, import qualified Window)
>
> then you get Button.f (because Graphics.UI.GTK wasn't imported qualified), 
> Graphics.UI.GTK.Button.f, (not f or Graphics.UI.GTK.f because of qualified 
> Button)  ... they're normal import statements inside.  What it saves is the 
> duplication of Graphics.UI.GTK and "....Button as Button".  Not sure I like 
> how long "import qualified" is, repeated there, but it seemed much less 
> confusing than anything shorter.
>
> import Data (import qualified Map, Map.Map)
> or
> import Data (import qualified Map, import Map(Map))
> or a shortcut for that common pattern of importing a few things unqualified
> import Data (import qualified Map and (Map))
> aka. import qualified Data.Map as Map and (Map)
> aka. import qualified Data.Map as Map (empty,singleton,...) and (Map)
> or perhaps "unqualifying" rather than "and"
>
> personally I would like it if we could also import (f as g) if we wanted to 
> rename an "f" we were importing, to "g" in the module and re-exports, without 
> having to be concerned about (for lowercase) monomorphism restriction, (for 
> types) whether a synonym will work properly everywhere (not without 
> extensions!), (for constructor, record fields, and classes) simple 
> *impossibility*.  That wish is only related in that it's a related 
> generalization, though.

nice