- Libraries - Haskell.org

Cabal bug?
by Niklas Broberg 11 Apr '05

11 Apr '05

The following works fine: hspr.cabal: -------------------------------------------- Name: hspr Version: 0.2 License: PublicDomain Author: Niklas Broberg Maintainer: nibro(a)cs.chalmers.se Build-Depends: base, haskell98, haskelldb, hsp Executable: hspr Main-Is: HSPR.hs -------------------------------------------- This does not: hspr.cabal -------------------------------------------- Name: hspr Version: 0.2 License: PublicDomain Author: Niklas Broberg Maintainer: nibro(a)cs.chalmers.se Build-Depends: base, haskell98, haskelldb, hsp GHC-Options: -F -pgmFtrhsx Executable: hspr Main-Is: HSPR.hs -------------------------------------------- > runhaskell Setup.hs configure Error: Non-empty library, but empty exposed modules list. Cabal may not build this library correctly The difference is the added GHC-Options, same thing happens if I try to add an Extensions rule. Is this an intended behavior? /Niklas

2 3

RE: exposed packages and cabal depends
by Simon Marlow 08 Apr '05

08 Apr '05

Hi Alex, On 08 April 2005 16:09, S. Alexander Jacobson wrote: > This choice adds complexity without adding value. It adds a lot of value: it will prevent untracked dependencies from creeping into Cabal packages. That's gotta be a good thing, right? With -hide-all-packages, there are no exposed packages by defualt, which is what you were arguing for! > The simplest approach would be for -i to take precedence over > default packages. That only partly solves the problem - you can still write source code that depends on environmental settings by importing modules from exposed packages. Even so, it seems a reasonable suggestion. We thought about it, but discovered that it leads to more problems: you can allow a local module M to override a module M in a package P only as long as nothing from P is required by any module in the current program. To know that, you have to examine all the modules in the current program, which is difficult when doing separate compilation. You could end up with some modules compiled in a context that thinks M is a local module, and others compiled thinking M comes from package P. Bad things probably happen, and it's not clear that we can always tell that this has happened before delivering the executable. At the least, the error turns up at unpredictable points (eg. when you turn optimisation on). > The -hide-all-packages approach creates much higher risk of testing > in a package context out of sync with the world at large. Hmm, I don't think you've understood what -hide-all-packages does. It gives you a *consistent* view of packages across all installations: it eliminates differences between what packages are exposed by default at different sites. That is a Good Thing. You'd probably be more comfortable if -hide-all-packages was the default. Well, I'm not going to argue with that, except to say that it probably will be the default when using Cabal. > What we really need is a community consensus system (wiki or dns) > for mapping module names to package locations and for > implementations to interpret modules in this context. Hackage will effectively provide a function from Module -> [Package] that's what you want, right? But we don't want a single centralised registry for module names, so it will also be possible to get packages from source other than Hackage. > Package names that are not URLs add complexity without value. Just think of all our existing packages as having an implicit prefix of http://haskell.org/packages/ (or something). Does that help? We'll get full URLs as package names in the future (at least, that's what I'd like to see). Cheers, Simon

3 2

RE: exposed packages and cabal depends
by Simon Marlow 08 Apr '05

08 Apr '05

On 31 March 2005 23:15, Isaac Jones wrote: > Ian Lynagh mentioned this problem to me a few weeks ago and Alex's > thread reminded me of it. This doesn't really relate to Alex's > proposal, so I'm starting a new thread. > > Let's say that from GHC's perspective, package A is exposed and > package B is hidden. Angela Author creates package C which > build-depends on both A and B. She incorrectly lists the > build-depends on B, but not on A. While building, she doesn't notice, > since A is an exposed package. > > This kinda sucks, since it would be nice to check build-dependencies > at build time. This is very similar to the situation in Debian where > a packager doesn't realize that there's a build-dependency on A, since > she's already got it installed, but when the auto-builders get to it, > the build fails since they don't have A installed. > > I don't know how to solve this; is there a way to require explicit > -package flags for all packages in ghc 6.4? If there were, say > -fhide-all-packages, then cabal could use that while building and > Angela would catch the error of her ways much earlier. I've now added -hide-all-packages. Cabal can start using this from GHC 6.4.1. Cheers, Simon

2 1

Data.Map, Data.Set working together
by Cale Gibbard 08 Apr '05

08 Apr '05

It just crossed my mind that due to the apparent similarity in implementation it might be possible to implement some extra functions on Maps which take Sets as parameters and which are more efficient than first going through lists. For instance: restrict :: Set a -> Map a b -> Map a b which would restrict the map's domain to the given set -- basically set intersection, but one of the objects is a map. fromFunction :: Set a -> (a -> b) -> Map a b Build a finite map in the obvious way from a set and a function. (basically, restrict the function on the potentially infinite domain a to the finite one given by the set, and record the result as a finite map) Depending on the way things work internally, perhaps the constructed Map could inherit the tree structure of the Set directly. Thoughts? I haven't really looked at the code, but it seems plausible that these sorts of operations where a Set and Map are involved could be done in a better fashion than going through association lists. - Cale

5 8

dead link on libraries page
by Benjamin Franksen 07 Apr '05

07 Apr '05

Hello, the libraries page (http://www.haskell.org/libraries/) lists "Sven's Haskell Libaries for interfacing to DaVinci, HTML/Cgi, OpenGL; a module for option handling, a Haskell parser, a binary library." The link is dead. Cheers, Ben

1 0

New function candidate for Network.URI
by Graham Klyne 07 Apr '05

07 Apr '05

Using Network.URI, I find I quite often want to do relative URI calculations on URI strings without explicitly handling URI values. I have a candidate function that might be added to Network.URI, with test cases: [[ -- Create a new URI string that is a supplied local URI relative -- to a given base URI, both supplied as strings. relativeToStr :: String -> String -> Maybe String relativeToStr rel base = do -- in Maybe monad: { b <- parseURIReference base ; r <- parseURIReference rel ; u <- r `relativeTo` b ; return $ (uriToString id u) "" } test_rs1 = ("foo" `relativeToStr ` "zz://auth/base/") == Just "zz://auth/base/foo" test_rs2 = ("abs://a/u" `relativeToStr ` "zz://auth/base/") == Just "abs://a/u" test_rs3 = ("[][]" `relativeToStr ` "zz://auth/base/") == Nothing test_rs4 = ("foo" `relativeToStr ` "[][]") == Nothing test_rs5 = ("foo" `relativeToStr ` "bar") == Just "foo" test_rs = and [test_rs1,test_rs2,test_rs3,test_rs4,test_rs5] ]] (I'm not sure the name is the best possible choice.) Is this kind of helper function useful to add to Network.URI? Maybe also a corresponding: relativeFromStr :: String -> String -> Maybe String ? #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

argument order of functions in Data.Bits
by Henning Thielemann 07 Apr '05

07 Apr '05

The version of Data.Bits which is shipped with GHC-6.2 is marked as experimental. So changes in the API are still possible? :-] My experiments suggest that the functions should have a different order of arguments. Many of the functions of this module alter some bits in a machine word, thus they can be considered as update functions and their type signature should end with a -> a. Then we could easily combine several operations this way shiftL 2 . clearBit 7 . setBit 4 . setBit 1 instead of flip shiftL 2 . flip clearBit 7 . flip setBit 4 . flip setBit 1 or (`shiftL` 2) . (`clearBit` 7) . (`setBit` 4) . (`setBit` 1) . I don't see the benefit of urging the programmer to use infix notation instead of prefix notation here, e.g. (w `shift` 2) instead of (shift 2 w).

2 1

RE: argument order of functions in Data.Bits
by Simon Marlow 07 Apr '05

07 Apr '05

On 07 April 2005 07:54, Henning Thielemann wrote: > The version of Data.Bits which is shipped with GHC-6.2 is marked as > experimental. So changes in the API are still possible? :-] > > My experiments suggest that the functions should have a different > order of arguments. Many of the functions of this module alter some > bits in a machine word, thus they can be considered as update > functions and their type signature should end with a -> a. Then we > could easily combine several operations this way > > shiftL 2 . clearBit 7 . setBit 4 . setBit 1 > > instead of > flip shiftL 2 . flip clearBit 7 . flip setBit 4 . flip setBit 1 > > or > (`shiftL` 2) . (`clearBit` 7) . (`setBit` 4) . (`setBit` 1) > . > > I don't see the benefit of urging the programmer to use infix notation > instead of prefix notation here, e.g. (w `shift` 2) instead of > (shift 2 w). On the whole I agree, but I'm inclined against changing this because it would break so much code gratuitously. I vote for just putting this down to a small mistake in the original design, and leaving it. If there's overwhelming support for the change of course we'll make it, but I doubt there will be. Also the order of the arguments to shift matches C's shift operators (although they are real infix operators, of course). Cheers, Simon

3 2

RE: Testing library modules
by Graham Klyne 07 Apr '05

07 Apr '05

At 11:59 07/04/05 +0100, Simon Marlow wrote: >In GHC you can say '-hide-package network' (or, perhaps better >'-ignore-package network') to remove the network package from the module >namespace. It will then use the local version instead. So it does! I *thought* I had tried that (per warning message from the compiler), but somehow it was still picking up the installed files. But on a renewed attempt, it now works fine despite having the installed files reinstated. Thanks. The proposed change to URI is now in CVS, the correct version having been tested (I think ;-). There's also an updated test harness. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

RE: Testing library modules
by Simon Marlow 07 Apr '05

07 Apr '05

On 07 April 2005 11:18, Graham Klyne wrote: > I've just discovered that my recent checkins of Network.URI were not > safe. I thought that I had run the changes against my test suite, > but just discovered that the test suite was actually being compiled > against the version of Network.URI shipped with GHC 6.4. > > I had expected the "-i" option on the GHC command line (see below) to > override the shipped version of Network.URI. > > As it happens, I've now checked the new module is OK by forcibly > renaming the Network.URI files that were installed with GHC 6.4. But > this raises a concern for me: how can I safely and reliably test a > replacement version of a GHC-shipped library module? In GHC you can say '-hide-package network' (or, perhaps better '-ignore-package network') to remove the network package from the module namespace. It will then use the local version instead. Cheers, Simon

1 0