RE: irrelevant package
On 14 June 2005 13:03, Duncan Coutts wrote: On Mon, 2005-06-13 at 16:06 +0100, Simon Marlow wrote: This is fixed in newer versions of Cabal. However, you are heading for problems here. When you install a package P that includes a module M, you prevent the user from having any modules called M unless they say '-hide-package P' (see previous discussions on this subject). For this reason, we strongly recommend using hierarchical module names. At the moment, Cabal exposes all the packages it imports. Perhaps we should have an option to install an unexposed package, to allow installation of packages that contain non-hierarchical module names. Isaac - what do you think? But remember that any exposed dependent package of P effectively exposes package P anyway. So it's not the case that you can install an unexposed package and assume that it'll all be ok. Any package installed later can come along and expose your package and you're back to the problem that no programs/libs with your module M can now be complied (without several -hide-package flags). A package is never exposed as a result of being depended on by another package, but its modules are brought into the module namespace. The difference is that you can import modules from an exposed package, you can't from a hidden package. This is true even if the hidden package is depended on by another exposed package. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: irrelevant package
On Wed, 2005-06-15 at 13:15 +0100, Simon Marlow wrote: But remember that any exposed dependent package of P effectively exposes package P anyway. So it's not the case that you can install an unexposed package and assume that it'll all be ok. Any package installed later can come along and expose your package and you're back to the problem that no programs/libs with your module M can now be complied (without several -hide-package flags). A package is never exposed as a result of being depended on by another package, but its modules are brought into the module namespace. The difference is that you can import modules from an exposed package, you can't from a hidden package. This is true even if the hidden package is depended on by another exposed package. True it is not exposed, but it's being brought into the module namespace. (effectively expose was not a good term for what I meant.) The point is, it is the being brought into the module namespace that's the problem. Using a flat module namespace in any library package P can pollute the module namespace for all other programs (even if the library is not exposed by default because any library package Q that uses P and is exposed will bring package P's modules into the module namespace). Then all those modules in package P will clash with modules of the same name in your own program even if you never import anything (directly or indirectly) from package P or Q. As I've mentioned before, the canonical example of this problem is the GetOpt module from the util package (part of the old hslibs collection of packages which use flat module names). If you install any library package (lets call it package foo-0.1) that uses the util package and is exposed then you can no longer use the module name GetOpt in any other program you compile from then on, even if none of that program's modules import any module from package foo-0.1 or util. That is, it breaks totally unrelated programs, eg happy in this example. I think the bug in this case is the fact that the modules are considered to be part your program even though they are never imported (directly or indirectly) or even any modules from the same package are imported (if we take the reasonable assumption that if one module from a package becomes part of your program's module namespace then all of them do). Duncan ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: irrelevant package
On 15 June 2005 13:49, Duncan Coutts wrote: I think the bug in this case is the fact that the modules are considered to be part your program even though they are never imported (directly or indirectly) or even any modules from the same package are imported (if we take the reasonable assumption that if one module from a package becomes part of your program's module namespace then all of them do). I agree, and I've been putting some serious thought into whether we can relax this restriction, and allow local modules to shadow package modules. Fortunately command-line linking works, because the linker links libraries lazilly. As long as we never have to use a linker that doesn't have this property, we're ok. We still have to check for real conflicts: where the package is really part of the dependencies of the program, and also shares a module name with the program. This can be checked for when compiling a module. GHCi just about copes, by virtue of linking in packages on demand. But, if you happened to require a package P and later changed the program so that it didn't need P any more but used a module name from P, you would have to restart GHCi. So, I think it's ok, just about. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: irrelevant package
On Wed, 2005-06-15 at 14:47 +0100, Simon Marlow wrote: On 15 June 2005 13:49, Duncan Coutts wrote: I think the bug in this case is the fact that the modules are considered to be part your program even though they are never imported (directly or indirectly) or even any modules from the same package are imported (if we take the reasonable assumption that if one module from a package becomes part of your program's module namespace then all of them do). I agree, and I've been putting some serious thought into whether we can relax this restriction, and allow local modules to shadow package modules. I'm not sure that allowing local modules to shadow package modules is really necessary in this case. There is the simpler (but very important) case where the local module doesn't shadow any package module - at least not a package that is used in the current program. So 'all' that needs to be done is to track which packages are actually used in a program (perhaps this is harder than I imagine). So if we never import any module from package Foo which depends on util-1.0 then util's modules are not brought into the module name space. GHC obviously does this correctly when linking, that is figure out which packages are used by the program, otherwise every program produced by ghc --make would be linked against absolutely every library used by every exposed package. So we just need to do the same thing when compiling and note that the module name space does not include modules from packages which are not imported. So an exposed packages modules (and therefore all of the modules in dependent packages) are not considerd to be part of the program's module namespace unless one or more of them is actually imported. So in the example the Gentoo packaging folk came up with of having a dummy.cabal package file that contains no modules (ie it contains no code and no libs) but is exposed and depends on util-1.0, then it should never be possible for this package to be considered to be used by the program since it exposes no modules and therefore none of its modules can be imported. In that case the fact that this dummy module would if it were used explicitly -package dummy bring all the util-1.0 modules into the program module namespace is now not a problem because it should never implicitly get imported because that should become imposiible. This would only solve the problem of totally unrelated programs failing to compile because of over-eager package imports. The problem of actually using a library that depends on a library that uses flat module names is obviously much harder, because in that case there genuinely is a module name clash. Duncan ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: irrelevant package
On 15 June 2005 15:19, Duncan Coutts wrote: On Wed, 2005-06-15 at 14:47 +0100, Simon Marlow wrote: On 15 June 2005 13:49, Duncan Coutts wrote: I think the bug in this case is the fact that the modules are considered to be part your program even though they are never imported (directly or indirectly) or even any modules from the same package are imported (if we take the reasonable assumption that if one module from a package becomes part of your program's module namespace then all of them do). I agree, and I've been putting some serious thought into whether we can relax this restriction, and allow local modules to shadow package modules. I'm not sure that allowing local modules to shadow package modules is really necessary in this case. There is the simpler (but very important) case where the local module doesn't shadow any package module - at least not a package that is used in the current program. So 'all' that needs to be done is to track which packages are actually used in a program (perhaps this is harder than I imagine). So if we never import any module from package Foo which depends on util-1.0 then util's modules are not brought into the module name space. GHC obviously does this correctly when linking, that is figure out which packages are used by the program, otherwise every program produced by ghc --make would be linked against absolutely every library used by every exposed package. So we just need to do the same thing when compiling and note that the module name space does not include modules from packages which are not imported. So an exposed packages modules (and therefore all of the modules in dependent packages) are not considerd to be part of the program's module namespace unless one or more of them is actually imported. Right, GHC does know the real package dependencies of the program, and it uses those for linking, but only for --make and GHCi. Ordinary batch linking (ghc Main.o -o foo) doesn't know the dependencies, and there's no good way for it to find out. But we currently require you to give explicit -package flags for batch linking, so I suppose this is ok. I called it shadowing because I think it is a kind of shadowing: when you import a module, the compiler has to search for it, and the proposal is that if the module is both on the local search path and in a package, then the local module takes precedence. GHC 6.4 currently takes the package module, and HEAD emits an error message in this case. I'm not proposing that you should be able to replace, say, Network.Socket with your own local version and yet still use the network package - that would definitely lead to problems, and the compiler should check for that. The problem with all this is that GHC internally has a function of type isHomeModule :: DynFlags - Module - Bool where DynFlags contains the package database. This becomes harder to implement if a package module can be a local module under certain circumstances... hmm, this isn't as easy as I thought. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: irrelevant package
On Mon, 2005-06-13 at 16:06 +0100, Simon Marlow wrote: This is fixed in newer versions of Cabal. However, you are heading for problems here. When you install a package P that includes a module M, you prevent the user from having any modules called M unless they say '-hide-package P' (see previous discussions on this subject). For this reason, we strongly recommend using hierarchical module names. At the moment, Cabal exposes all the packages it imports. Perhaps we should have an option to install an unexposed package, to allow installation of packages that contain non-hierarchical module names. Isaac - what do you think? But remember that any exposed dependent package of P effectively exposes package P anyway. So it's not the case that you can install an unexposed package and assume that it'll all be ok. Any package installed later can come along and expose your package and you're back to the problem that no programs/libs with your module M can now be complied (without several -hide-package flags). Duncan ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
irrelevant package
Dear GHC developers, I am testing packages in ghc-6.4. I set docon.cabal, which declares dependence on `data': build-depends: data The attempt to build docon by cd $doconSource runhaskell Setup.hs configure --ghc --prefix=$doconSource/inst runhaskell Setup.hs build produces configuring ... compiling ... ... DPrelude.hs:1:0: Module `DPrelude' is a member of package dumatel-1.2.6.4. To compile this module, please use -ignore-package dumatel-1.2.6.4. These does exist a package dumatel-1.2.6.4, and both the above packages have DPrelude among the module names. But why does Cabal look into irrelevant package? The dependence is set: only `data'. ghc-pkg -l shows /usr/lib/ghc-6.4/package.conf: rts-1.0, base-1.0, haskell98-1.0, template-haskell-1.0, unix-1.0, Cabal-1.0, parsec-1.0, haskell-src-1.0, network-1.0, QuickCheck-1.0, HUnit-1.1, mtl-1.0, fgl-5.2, X11-1.1, HGL-3.1, stm-1.0, readline-1.0, (lang-1.0), (concurrent-1.0), (posix-1.0), (util-1.0), (data-1.0), (text-1.0), (net-1.0), (hssource-1.0) /home/mechvel/.ghc/i386-linux-6.4/package.conf: dumatel-1.2.6.4 The package specification is -- name:docon version: 2.9 license-file:../../license.txt copyright: Serge Mechveliani (2005) author: Serge Mechveliani maintainer: [EMAIL PROTECTED] homepage:http://www.botik.ru/pub/local/Mechveliani/docon/ package-url: http://www.botik.ru/pub/local/Mechveliani/docon/ http://www.haskell.org/docon/distrib/ synopsis:computer algebra program written in Haskell tested-with: GHC build-depends: data exposed-modules: DExport DPrelude Categs SetGroup RingModule DPair Z Fraction VecMatr LinAlg Pol GBasis Residue Permut Partition AlgSymmF . other-modules: Iparse_ OpTab_ Categs_ DPair_ Matr0_ Ring0_ Semigr_ Vec1_ Char_ Fract_ Matr1_ Ring1_ Set_ Vec_ Common_ List_ Prelude_ Ring_ Vec0_ Det_ Stairc_ Todiag_ IdealSyz_ ResEuc0_ ResEuc_ ResRing__ RsePol0_ QuotGr_ ResEuc1_ ResPol_ ResRing_ RsePol_ EPol0_ Pgcd_ Pol_ RPol0_ EPol1_ FreeMonoid Pol1_ PolNF_ RPol_ EPol_ GBasEuc_ Pol2_ Polrel_ FAA0_ GBasFld_ Pol3_ PP_ UPol0_ FAANF_ GBas_ Pol__ RdLatP_ UPol_ Pfact0_ Pfact1_ Pfact2_ Pfact3_ Pfact__ Pfact_ HookBand_ Partit_ SymmFn0_ SymmFn1_ SymmFn_ Sympol_ . ghc-options: -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances -fno-warn-overlapping-patterns -fwarn-unused-binds -fwarn-unused-matches -fwarn-unused-imports --- With kind regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: irrelevant package
On 13 June 2005 14:34, Serge D. Mechveliani wrote: I am testing packages in ghc-6.4. I set docon.cabal, which declares dependence on `data': build-depends: data The attempt to build docon by cd $doconSource runhaskell Setup.hs configure --ghc --prefix=$doconSource/inst runhaskell Setup.hs build produces configuring ... compiling ... ... DPrelude.hs:1:0: Module `DPrelude' is a member of package dumatel-1.2.6.4. To compile this module, please use -ignore-package dumatel-1.2.6.4. These does exist a package dumatel-1.2.6.4, and both the above packages have DPrelude among the module names. But why does Cabal look into irrelevant package? The dependence is set: only `data'. This is fixed in newer versions of Cabal. However, you are heading for problems here. When you install a package P that includes a module M, you prevent the user from having any modules called M unless they say '-hide-package P' (see previous discussions on this subject). For this reason, we strongly recommend using hierarchical module names. At the moment, Cabal exposes all the packages it imports. Perhaps we should have an option to install an unexposed package, to allow installation of packages that contain non-hierarchical module names. Isaac - what do you think? Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
