[Haskell-cafe] Packages and modules
brianh at metamilk.com
Sun Jun 25 17:00:29 EDT 2006
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
> 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
> 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.
> 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
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.
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 Haskell-Cafe