- Libraries - Haskell.org

RE: irrelevant package
by Simon Marlow 15 Jun '05

15 Jun '05

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

1 0

RE: irrelevant package
by Simon Marlow 15 Jun '05

15 Jun '05

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

2 1

RE: irrelevant package
by Simon Marlow 15 Jun '05

15 Jun '05

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

2 1

Default prefix for Cabal on Windows
by Brian Smith 15 Jun '05

15 Jun '05

Hi all, The documentation states in Section 3.1 that the default value of "prefix" is "/usr/local" on Unix. However, it doesn't specify what the prefix is on Windows. I found that the default value for prefix is: C:\Program Files\<package-name>\<compiler-name>-<compiler-version>. For example, version 1.0 of a package named "Foo" compiled with GHC 6.5 would have a default prefix of: C:\Program Files\Foo\ghc-6.5 I think that a better default value of prefix on Windows would be: C:\Program Files\<package-name>-<package-version> e.g.: C:\Program Files\Foo-1.0 In particular, I think it is undesirable to have the name and version of the compiler embedded in the default prefixes. Regardless of whether or not it is changed, this would be another good thing to put into the documentation. Regards, Brian

1 0

RE: irrelevant package
by Simon Marlow 14 Jun '05

14 Jun '05

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

2 1

Re: [Haskell-cafe] Notes and questions from a first-time Cabal user.
by ross＠soi.city.ac.uk 14 Jun '05

14 Jun '05

[moving to libraries] On Mon, Jun 13, 2005 at 05:28:43PM -0500, Brian Smith wrote: > * If I use "Executable: check-ocl2," then under Windows the > executable's name really becomes "check-ocl2.exe." This is desireable > behavior. But, this causes "Setup.hs copy" and "Setup.hs install" to > fail because it tries to copy a file named "check-ocl2" (without the > ".exe"), which obviously doesn't exist. That's a bug in copy/nstall. > * The tutorial documentation should explain how to use tools like alex > and happy. As far as I could tell, the way to do this is to add > "Other-Modules: Module.Name.Of.Parser.y Module.Name.Of.Lexer.x" to > each executable/library stanza. But, I am not sure why this is > necessary, as it seems like it should be able to find them > automatically (i.e. without having to list them in the Other-Modules: > field) The .y and .x shouldn't be part of the module name. It's all much the same as for .hs. The Other-Modules field could be inferred from Main-Is or Exposed-Modules, but it isn't. > * Is there some way to tell Cabal to generate all intermediate files > into a directory that is different than the source directory? I > usually keep all my sources in a "src" directory, and then generate > all .hi, .o, and .hs files from Happy and Alex into a "build" > directory alongside it. This way, my "src" directory only contains > stuff that belongs in my version control repository, and "make clean" > was simply "rm -Rf build." Cabal puts the generated files in dist/build, along with copies (or cpp's) of the source files. > * If I run "runghc ./Setup.hs" I get this message: > No command given (try --help). > This is confusing because it isn't clear that it is a cabal error > message and not a runghc error message. That is, it isn't clear > whether to run "runghc --help" or "runghc Setup.hs --help," and both > commands are valid. The message should be improved, or "--help" should > be the default command. Those error messages ought to be prefixed with the program name (and should go to stderr too). > * Chapter 2 needs to be updated to replace "Hs-Source-Dir" with > "Hs-Source-Dirs," since Hs-Source-Dir is deprecated. The CVS version of the docs are updated; the web version describes GHC 6.4. > * Chapter 2 of the documentation states that identifiers can contain > underscores. However, Cabal gives "*** Exception: Line 1: Parse of > field 'name' failed" if I use "Name: ocl2_haskell" whereas "Name: > ocl2haskell" works fine. > > * Chapter 2 of the documentation states that identifiers must start > with a letter. However, "Name: 2" is parsed without complaint. Yes, the docs are wrong: a package name is actually one or more alphanumeric words separated by hyphens (though to avoid ambiguity each word should contain at least one letter), while identifiers are as in Haskell. > * Chapter 2 of the documentation states that idenfiers must start with > a letter. However, "letter" is not defined. Presumably the intention > is to restrict identifiers to English letters only? Haskell 98 defines a letter, but it doesn't say how to interpret a text file containing non-ASCII bytes. > * I originally put my "Build-depends: base" in an "Executable:" > stanza. This seems reasonable because presumably different executables > (and libraries) could have different dependencies, and it is > advantageous to keep track of dependencies on a fine-grained basis. > Yet, Cabal requires the Build-depends to be in the main stanza. Why is > this? Couldn't Cabal combine all the Build-Depends it finds into the > one that it puts into the final package specification? It is confusing that the first stanza contains both fields describing the whole package and fields describing a library. But Build-depends is a package-level thing (it's not in 2.1.2) because Cabal takes the package as the unit of distribution, building, etc. If you want to build this pachage, these are the other packages you need to have installed first. There has been some talk of a coarser level of structure in the indefinite future. > * Chapter 2 of the documentation states that I should be able to use > syntax like "foo > 1.2" in Build-depends, but I could not get "HUnit > > 1.1" or "HUnit >= 1.1" to work; they fail with parser errors. Hmm, the parser can't cope with white space after the relational operator -- another bug.

3 2

RE: What Cabal stuff is permanent?
by Simon Marlow 13 Jun '05

13 Jun '05

On 08 June 2005 16:38, John Goerzen wrote: > On 2005-06-07, Isaac Jones <ijones(a)syntaxpolice.org> wrote: >> include-dirs gets put into ghc's package.conf file, correct? But >> then > > While we're at it, it seems that GHC 6.4 no longer has a library-dirs > option, Not sure what you mean here - ghc-pkg's package format (aka InstalledPackageInfo) definitely *does* have a library-dirs field. > and that extra-lib-dirs is *not* installed into the GHC > package file. I think that it should be. What do you think? Indeed, that looks like a bug. I'm testing the fix now. Cheers, Simon

2 1

Haskell Matrix Library
by Keean Schupke 09 Jun '05

09 Jun '05

Hi, I have a simple matrix library (styled after MatLab's use of matrices), and was wondering if any of the standard libraries include matrix functionality. The library as stands is not suitable for general use - but it could be adapted. I guess the questions are: - is there already a matrix library in the standard libraries? - is anyone interested in a matrix library? - would people want a library like MatLab where matrices are instances of Num/Fractional/Floating and can be used in normal math equations... - operations like cos/sin/log can be applied to a matrix (and apply to each element like in MatLab)... What do people think? Keean

1 0

RE: What Cabal stuff is permanent?
by Simon Marlow 08 Jun '05

08 Jun '05

On 07 June 2005 14:29, Duncan Coutts wrote: > On Tue, 2005-06-07 at 08:15 -0500, John Goerzen wrote: >> On Tue, Jun 07, 2005 at 02:06:34PM +0100, Duncan Coutts wrote: >>>> of this library" through Cabal. >>> >>> I suspect that any C .h files you need at build time will also be >>> needed by programs which use the library that you are building, >>> since GHC can inline FFI calls across modules in which case the >>> client module needs the .h files when compiling too. And so they >>> should be installed along with your library (assuming it is a >>> library and not a program you're building) and their location >>> mentioned in the .cabal file. >> >> Hmm. I have had several cases where I haven't included these .h >> files, and things still seem to have worked OK. I do that in >> MissingPy, for instance. I know that WASH has a .h file that it has >> not traditionally installed. > > You're probably just lucky that GHC decided not to inline the FFI > call. :-) (and/or the client module was not being compiled -fvia-C) > > You can get the definitive answer as to whether you're on thin ice > from one of the GHC devs. Yes, you're on thin ice. You should assume that any header files required to compile the current module (via C) will be required to compile any module that depends on it. However, if you attach includes to foreign import declarations, like this: foreign import ccall "foo.h bar" bar :: ... then GHC will currently not inline bar in another module. This is a missing feature, and we might fix it at some point. If you use Cabal's "includes" directive, or GHC's -#include option, rather than naming header files in the foreign declaration, then your foreign calls can and will cross module boundaries. You could work around it by not compiling certain modules with -O, or perhaps something funky like {-# OPTIONS_GHC -funfolding-creation-threashold=0 #-} might work (please let us know if it does!). I don't think Cabal currently has support for installing .h files, I guess that's something we need to look into (Isaac?). Cheers, Simon

3 4

RE: What Cabal stuff is permanent?
by Simon Marlow 08 Jun '05

08 Jun '05

On 07 June 2005 16:54, Isaac Jones wrote: > John Goerzen <jgoerzen(a)complete.org> writes: > >> On Tue, Jun 07, 2005 at 04:04:12PM +0100, Simon Marlow wrote: >>> However, if you attach includes to foreign import declarations, >>> like this: >>> >>> foreign import ccall "foo.h bar" bar :: ... >>> >>> then GHC will currently not inline bar in another module. This is a >>> missing feature, and we might fix it at some point. >> >> Ah ha. That is the only style I've ever used, and is also what WASH >> uses. So I guess I get out of jail free. >> >>> I don't think Cabal currently has support for installing .h files, I >>> guess that's something we need to look into (Isaac?). >> >> Sounds like it. > > How would this look? Let's say that include-dirs=./includes or > something relative to the top of the source tree while building. This > is so that ghc can find the "includes" while building. > > include-dirs gets put into ghc's package.conf file, correct? But then > will the installed package need an absolute path for include-dirs? Or > can it be relative to ghc's library directory or the package root? If > the later, it sounds like no big deal, just create the directory and > put anything from the "includes" field into it while installing. > > But then sometimes the include dirs might be an absolute path, maybe? > To indicate a .h file that this package is build-depending on? In > which case, we might assume that the include files in there are not a > part of the package, so we don't try to install them, but they are a > dependency and they should be installed on the target system already. > > If ghc's package.conf file doesn't allow relative paths, then we have > to do something a little tricky when generating the package.conf file, > which is make up the location that the includes will go. > > Sounds a little harry, but doable. Does anyone have better ideas? That does sound a little harry, you're right (sorry :-). I suggest adding a couple of new fields to .cabal. eg: local-include-dirs: includes install-includes: includes/myheader.h The purpose of local-include-dirs is that it adds -I flags to the ghc command line for building (only). The purpose of install-includes is: - it lists header files to install - they get installed in location specified by the --includedir option to ./setup configure, or otherwise a defaulit -- perhaps /usr/include/<package>, or maybe $libdir? C code that needs to include these headers can be compiled with "ghc -package P" and get the right -I option automatically. - the package.conf we generate for GHC will contain $includedir in include-dirs, iff install-includes is non-empty. Sound reasonable? Cheers, Simon

1 0