Packages and modules

Brian Hulley brianh at
Tue Jul 4 20:03:01 EDT 2006

Simon Peyton-Jones wrote:
> Concerning other mail on this subject, which has been v useful, I've
> revised the Wiki page (substantially) to take it into account.
> Further input (either by email or by adding material to the Wiki)
> would be welcome.  (No guarantee Simon M agrees with what I've
> written... I'm at home this afternoon :-)

I think the following is a non-question:

      An open question: if A.B.C is in the package being compiled,
      and in an exposed package, and you say import A.B.C,
      do you get an error ("ambiguous import"), or does the current
      package override.

because if the suggested syntax is used, import directives come in two 
flavours: ones that use "from" to import from a different package and ones 
that don't use "from" and therefore must refer to the current package. There 
would be no such thing as an "exposed" package (afaiu the idea of "exposure" 
is only needed in the context of different packages needing to share the 
same module namespace, which the proposal will hopefully make a thing of the 

Here are some other points:

1) What is the meaning of ?
I think this would have to refer to id in the module A.B.C in the package 
being compiled. To refer to an id in some other package, you'd have to use 
an alias eg

   import qualified A.B.C from "base" as P -- P refers to the aliased module

(Aliases hide modules in the current package with the same modid when that 
modid is used to qualify something)

To avoid the need to use aliases here, a different syntax eg Base/ 
would need to be used (where Base is a package alias for "base") but it 
seems unlikely that anyone would find a reason to not want to use an alias 
in such cases so this other syntax wouldn't be necessary.

2) Exporting modules from other packages.
(This also relates to the Haskell' proposal for qualified exports at )

2a) Exporting the contents of an external module

       module Foo
                ( module P
                ) where

       import qualified A.B.C from "extpkg" as P

2b) Exporting the contents of an external module qualified

       module Foo
                ( qualified module P
                ) where

       import qualified A.B.C from "extpkg" as P

In both cases an alias would be needed so we can refer to the external 
module in the export list without having to repeat the 'from "extpkg"' here 
as well. And since we are using aliases, it makes sense to modify the 
poposed H' syntax to allow

      qualified module M

to be short for:

      qualified module M as M

where M is either an alias or a module in the current package.

3) Syntax:
I liked Ian Lynagh's suggestion of using "from" to start either a single 
import directive or a block of import directives eg 
(modified to use quotes):

    from "base"
            import Predude hiding(length)
            import Control.Exception
            import qualified Data.List as List

since otherwise it would soon become a bit of a pain to have to type 'from 
"base"' everywhere (esp if the package name was some long URL). It would 
also make it easier to quickly change to a different package without having 
to modify multiple import directives, which might be especially useful in 
the context of using a debug or release version of a package by putting C 
pre-processor directives around the "from" part.

There is a minor open question about the exact indentation rule for the 
above syntax since "base" is not a keyword and it would seem strange to 
desugar it into from {"base"; import ... } so it looks like it would need a 
special layout rule that would give a desugaring into from "base" {import 

Regards, Brian.
Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us. 

More information about the Glasgow-haskell-users mailing list