I'm not sure on which mail of this thread I should append MHO.
What happens if two programmers happen to choose the same package
name? (Prepend the location on the filesystem? ;-)
If something like a package name is introduced I would prefer not
separating package and module name with a .
Marc Weber wrote:
I'm not sure on which mail of this thread I should append MHO.
What happens if two programmers happen to choose the same package
name? (Prepend the location on the filesystem? ;-)
If something like a package name is introduced I would prefer not
separating package and module
Simon Peyton-Jones wrote:
Simon and I have been thinking about fixing this, and we think we
might actually do so for GHC 6.6. Your message provoked us to write
up the design. It's here
http://hackage.haskell.org/trac/ghc/wiki/GhcPackages
Feedback welcome
It's worth reading the old threads;
Brian Hulley wrote:
import Gtk/Widget.Button -- instead of grafting
In all cases I think it would be an absolute disaster to allow
modules to be imported without an explicit package id because this
would defeat the whole purpose of having a simple per-package
namespace for modules and
On Mon, Jun 26, 2006 at 04:20:16PM +0100, Brian Hulley wrote:
I don't think this solves the whole problem. Suppose M1 needs to use A.B.C
from P1 *and* A.B.C from P2
For a simple example of a case where this might arise, suppose M1 is the
migration module for data (stored in a database,
Simon,
We covered this extensively in the Cabal vs Haskell thread starting
here: http://www.haskell.org//pipermail/libraries/2005-April/003607.html
You concluded it by saying on April 22:
And this observation points towards a simpler solution: rather than
invisibly pre-pend the package
