[Haskell-cafe] Design your modules for qualified import
lemming at henning-thielemann.de
Sun Jun 15 15:41:40 EDT 2008
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)
> 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.
More information about the Haskell-Cafe