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
http://www.haskell.org//pipermail/libraries/2005-August/004281.html
But there are many others!
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brian
| Hulley
| Sent: 25 June 2006 10:16
| To: Haskell-cafe
| Subject: [Haskell-cafe] Packages
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;
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,
Of Brian
| Hulley
| Sent: 25 June 2006 10:16
| To: Haskell-cafe
| Subject: [Haskell-cafe] Packages and modules
|
| Hi -
| At the moment there is a problem in that two packages P and Q could
contain
| the same hierarchical module eg Data.Foo, and the only way for user
code to
| ensure the right
Hi -
At the moment there is a problem in that two packages P and Q could contain
the same hierarchical module eg Data.Foo, and the only way for user code to
ensure the right Data.Foo is used is to ensure that packages P and Q are
searched in the right order.
However suppose P and Q also
Apologies to Brian for the multiple copies, this wasn't originally
sent to the list.
On 25/06/06, Brian Hulley [EMAIL PROTECTED] 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
David House wrote:
Apologies to Brian for the multiple copies, this wasn't originally
sent to the list.
On 25/06/06, Brian Hulley [EMAIL PROTECTED] 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
On Sunday 25 June 2006 05:16 am, Brian Hulley wrote:
Hi -
At the moment there is a problem in that two packages P and Q could contain
the same hierarchical module eg Data.Foo, and the only way for user code to
ensure the right Data.Foo is used is to ensure that packages P and Q are
searched
Robert Dockins wrote:
On Sunday 25 June 2006 05:16 am, Brian Hulley wrote:
[snip]
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?
[snip
11 matches
Mail list logo