Brian Hulley wrote:
Simon Peyton-Jones wrote:
http://hackage.haskell.org/trac/ghc/wiki/GhcPackages

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 past).

I wonder if the wiki question refers to issues of backwards compatibility with the existing module system? Ie do you want to keep the existing module system with (all exposed) packages sharing the same module space at the same time as having a new module system with per-package namespaces?

To allow both to exist simultaneously, I suggest a new keyword (and improved syntax below) to mark a per-package namespace import so that existing code using "import A.B.C" would still refer to the existing overlapped namespaces so that there wouldn't be any problems with backwards compatibility (except for the introduction of a new keyword) eg:

     use "base"
             Prelude hiding(length)
             qualified Data.List as List

     use A.B.C -- from current package

import P.Q.R -- deprecated old-style import from current + exposed packages

With this new syntax, my answer to the wiki question would be that the compiler should respond to "import A.B.C" where A.B.C is in an exposed package exactly as it does at the moment, whatever way that is, since people can always choose to resolve the ambiguity properly using the new syntax.

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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to