[Haskell-cafe] Packages and modules

[Brian Hulley]

David House wrote:
> Apologies to Brian for the multiple copies, this wasn't originally
> sent to the list.
>
> On 25/06/06, Brian Hulley <brianh at metamilk.com> wrote:
>> I'm wondering: would it not be easier to just make it that the
>> package name is prepended to the hierarchical module name, so the
>> modules would instead be called by the names P.Data.Foo and
>> Q.Data.Bar?
>
> This has the disavantage that if you move a module from one package to
> another, all existing code using that module breaks.

Existing code also breaks when you rename a module, although perhaps that's 
not so common as moving a module to another package (it's probably just me 
that has a bad habit of always wanting to rename everything later ;-) )

>
> Perhaps we need something analoguous to qualified imports: as well as
> specifying the modules hierarchical path, you could also specify its
> package. E.g.,
>
> import Network.HTTP from HTTP
>
> Or, using your syntax:
>
> import HTTP.Network.HTTP

[rearranged]

> Also, ambiguity. Given 'import
> HTTP.Network.HTTP', the compiler has to search for both packages named
> HTTP and modules with a full hierarchical name of HTTP.Network.HTTP.
> In the unlikely sitatution where a different package did indeed
> provide a module called HTTP.Network.HTTP, there would be an overlap.
>
> Finally the compiler could give better error messages if the module
> doesn't exist. I.e. one of 'Package X not found' or 'Module Y not
> found within package X' instead of 'Module Y not found'.

I agree with the advantages of making the package part explicit for 
preventing ambiguity and getting better error messages.

[rearranged]

> I prefer mine because we could also allow not qualifying the package:
>
> import Network.HTTP -- will search all known packages for a
> Network.HTTP package
> This is likely to be less of a pain in the majority of cases when the
> module names don't overlap.

I think though that a problem with allowing the package part to be omitted 
would be that when code is shared people would get different results when 
trying to compile it depending on which packages they happen to have 
installed. At the moment, although different packages can define modules 
with the same name, everyone afaik takes great care to try and avoid this so 
that the hierarchical namespace is hopefully "unique" regardless of the 
search order of packages.

However if we are allowed to qualify a hierarchical name by a package name, 
we might end up with a lot less "uniqueness" in the hierarchical namespace 
(since this is partly the whole point since uniqueness can't be guaranteed 
at the moment anyway unless everyone knows about everything that everyone 
else is developing or intending to make globally available) leading to more 
unintended combinations of modules when they're imported unqualified.

Therefore to get 100% safe code (assuming uniqueness of package names), I 
think it would be better to make the package qualification mandatory.

> import Network.HTTP from HTTP
   import qualified Newtork.HTTP from HTTP as H

Other possibilities:

   import HTTP\Network.HTTP
   import Com.Company\Network.HTTP

   package Com.Company as C  -- a package alias
   import qualified C\Network.HTTP as H

Not that I'm necessarily suggesting \ but just trying to find some character 
that is easy to type (perhaps /) and can also be used in the lexical syntax 
without making too much impact on the CFG.

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.

http://www.metamilk.com