- Libraries - Haskell.org

RE: Stop untracked dependencies! (was RE: mapping module identifiers toURLs (was RE: [Haskell] URLs in haskellmodule namespace))
by Simon Marlow 01 Apr '05

01 Apr '05

On 31 March 2005 20:07, S. Alexander Jacobson wrote: > If I use multiple packages that export the same module identifier, I > need a way to specify which one I want to use. Haskell's existing > packaging model doesn't let met do that easily. That's because there are problems with doing so, as I mentioned in an earlier message: http://www.haskell.org//pipermail/haskell/2005-March/015597.html We don't allow programs to contain two modules with the same name, for good reasons. >> - Cabal could download, build, and install dependencies without any >> user intervention. > > Download and build? Great! Install? No thank you! When I say "install" I don't necessarily mean "make it available by default for all users on the current machine". It might just mean "make it available just for me, and only when I say -package P". Or it might mean something even more transient: just make it available for the current compilation. Cheers, Simon

1 0

RE: Stop untracked dependencies!
by Simon Marlow 01 Apr '05

01 Apr '05

On 01 April 2005 09:27, Malcolm Wallace wrote: > I recall that Cabal had (at some early design stage) the ability to > specify a range of version numbers on each package dependency, e.g. > Foo requires Bar, any version between 1.2 and 1.8. The ranges are > open, so you could say "anything > 6.2" for instance. Cabal does have this: you can specify version ranges, and even union/intersect them. I agree with everything else in Malcolm's message... Cheers, Simon

1 0

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

01 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 think the situation for "run-time" dependencies is similar. You can find the dependencies in .hi files. eg: $ ghc --show-iface Main.hi | grep '^package dep' package dependencies: base-1.0 haskell98-1.0 The dependencies for the whole library are the union of the package dependencies of the exposed modules. It should be pretty easy to implement './setup check-dependencies' in Cabal. Perhaps ghc --make could have an option to print the dependencies at the end of compilation, too. Cheers, Simon

1 0

Re: Stop untracked dependencies!
by Isaac Jones 01 Apr '05

01 Apr '05

"S. Alexander Jacobson" <alex(a)alexjacobson.com> writes: > A major problem in every major language I have ever used is module > systems that make it all too easy for untracked dependencies to creep > silently into code. The result has repeatedly been nasty surprises > when moving code between machines. A Haskell example of this problem > might look something like this: > > * Oh, Network.HTTP is non-standard!? Thats wierd. > * Uh Oh. Google reveals at least three different implementations... > * Now, how do I determine which one is installed here? > * Is there a local copy of the package somewhere? > * No? Ok, is it available for download somewhere? > * Uhm, is the version I am using still available for download? > * Oh, we made local changes too!? What were they? > * Ok, we added Network.Socket.SSL. That's standard right? [rinse/repeat] > [A lot of detective work later...] > * Ok, now we've figured out all the packages, how do we ship them? > [shipping strategy devised...] > * But what happens if I don't have root/admin on the target machine? [...] > * Oh, this package conflicts with something already installed? [etc.] What does this example have to do with untracked dependencies? Sounds like more of a problem with a lack of a central database ala Hackage. >> It is true that Cabal's Build-Depends doesn't do everything you want it >> to, but your proposal also duplicates some of the functionality of >> Build-Depends, and makes it so that there are two places where >> dependencies are stored. We should only have to specify dependencies >> once. > > I agree you should only have to specify dependencies once. But, > deferring dependency tracking to the point you are ready to ship (with > Cabal or otherwise) is a recipe for disaster. Actually, it gets checked at build time if you use cabal to build during development. This can fail for (ghc-pkg) exposed packages, though, see the message I just posted. > Strawman proposal 2: > > Modify the import syntax to allow package identifiers: > > import qualified HaXML HaXML.XML.Parse > import HAppS HAppS.ACID > import Personal MyLib Can you relate this proposal to the previous grafting work? It sounds like you're basically just adding a new root to the module hierarchy. My $0.02: I'm still more comfortable with solving this outside the core language, with the package system, cabal, and hackage. (snip) >> I don't think it's necessary to specify dependencies with module >> granularity. This just increases the number of possible error cases, >> without adding functionality. > > If I use multiple packages that export the same module identifier, I > need a way to specify which one I want to use. Haskell's existing > packaging model doesn't let met do that easily. Does the grafting proposal solve this problem? >> - Package dependencies in Build-Depends could be specified using >> URLs. > > But then dependencies aren't checked at compile time and you can't > specify which modules come from which packages. > >> - Cabal could download, build, and install dependencies without any >> user intervention. > > Download and build? Great! Install? No thank you! FWIW, right now (thanks to Lemmih), Hackage has a client-server interface so that the client can query hackage as to the dependencies for a given package, and the URLs. So you'll be able to "caball-get foo" and it'll download and install foo's dependencies along with foo. Since it'll be source-packages only (at least at first), there's no "cabal-get build-dependencies-of foo", since to use foo you'll need the build and run-time dependencies. peace, isaac

3 2

exposed packages and cabal depends
by Isaac Jones 31 Mar '05

31 Mar '05

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 think the situation for "run-time" dependencies is similar. peace, isaac

1 0

RE: mapping module identifiers to URLs (was RE: [Haskell] URLs in haskellmodule namespace)
by Simon Marlow 31 Mar '05

31 Mar '05

On 30 March 2005 16:27, Ross Paterson wrote: > [switching to libraries] > > On Wed, Mar 30, 2005 at 12:02:30PM +0100, Simon Marlow wrote: >> I don't think it's necessary to specify dependencies with module >> granularity. This just increases the number of possible error cases, >> without adding functionality. If you want to specify which module >> imports require each package dependency, then do it with a comment. >> The tools can tell you if any dependencies are redundant. >> >> Suppose that: >> >> - Package dependencies in Build-Depends could be specified using >> URLs. > > That would also be redundant. Better to keep using package names in > dependencies, and have a catalogue mapping package names to URLs, > either in a local file or a remote database (i.e. Hackage). I expect the default would be to look for a package in the main Hackage repository, so for example 'network' might be interpreted as shorthand for 'http://haskell.org/packages/network'. For packages not in the main Hackage repository, there needs to be an absolute URL somewhere: that can be in the .cabal file, or in a separate file if you like. If a separate file is used, then it should travel with the package, because a package should be self-contained. Cheers, Simon

1 0

Re: mapping module identifiers to URLs (was RE: [Haskell] URLs in haskellmodule namespace)
by Ross Paterson 30 Mar '05

30 Mar '05

[switching to libraries] On Wed, Mar 30, 2005 at 12:02:30PM +0100, Simon Marlow wrote: > I don't think it's necessary to specify dependencies with module > granularity. This just increases the number of possible error cases, > without adding functionality. If you want to specify which module > imports require each package dependency, then do it with a comment. The > tools can tell you if any dependencies are redundant. > > Suppose that: > > - Package dependencies in Build-Depends could be specified using > URLs. That would also be redundant. Better to keep using package names in dependencies, and have a catalogue mapping package names to URLs, either in a local file or a remote database (i.e. Hackage). > - Cabal could download, build, and install dependencies without any > user intervention. And this is also on the way, I hear.

1 0

Data.Map questions
by Johannes Waldmann 30 Mar '05

30 Mar '05

Data.Map (in ghc-6.4) has instances for Ord and of Show (which FiniteMap didn't have). What does Ord guarantee? I hope it is a total ordering compatible with (==) (so that Maps could be elements of Sets etc.) If so, perhaps there should be a comment in the documentation. From reading the source ghc-6.4/libraries/base/Data/Map.hs it is not clear why Eq uses toAscList but Ord uses toList - so perhaps there is some hidden magic? What if I don't like the Show instance? (That seems to be a fundamental question of library design/usage.) I prefer to have show x return some string that can be pasted back into the source code (!) and gives the correct result. So, for FiniteMap I had sth. like show fm = "listToFM [ (1, True), (2, False) ]" It seems I cannot hide the Show instance from Data.Map (it is always in scope, http://www.haskell.org/onlinereport/modules.html#sect5.4) Perhaps it would be better to have the Show instance in a separate module (that is not automatically imported). Because if I want to use a Map with my preferred Show instance now, I would have to declare my own newtype and instantiate that. - Maybe that's better design anyway (not exposing the concrete implementation). It still fixes one implementation, though. The next step would be to use a type class, but this severely blows up the type signatures. With this respect, "corresponding" Java programs really look better, allowing Map<Foo,Bar> f = new HashMap<Foo,Bar>(); where Map is the interface, and HashMap is one implementation, and the rest of the program only knows that f implements the interface. Yes I know that syntax is only possible because their type classes (interfaces) have exactly one parameter ... Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------

3 2

SDL bindings.
by Lemmih 29 Mar '05

29 Mar '05

Greetings, I've hacked up a simple binding to SDL and some of the addons. Darcs repo at http://www.scannedinavian.org/~lemmih/SDL/ -- Friendly, Lemmih

1 0

RE: The FunctorM library
by Simon Marlow 29 Mar '05

29 Mar '05

On 20 March 2005 23:30, Thomas Jäger wrote: > Aside from naming issues, there seem to be some problems with the way > FunctorM is currently implemented. > > First of all, `FunctorM` should be a superclass of `Functor' because > there is an obvios implementation of fmap in terms of fmapM >> import Data.FunctorM >> import Control.Monad.Identity >> >> fmap' :: FunctorM f => (a -> b) -> f a -> f b >> fmap' f = runIdentity . fmapM (return . f) > It is already annyoing enough that `Funtor' isn't a subclass of > `Monad' although every monad must also be functor. > > Now, FunctorM should be based on the simplest operations possible, > which in this case is the distributive law and not a monadic version > of fmap (which might be provided for efficiency reasons). > >> class Functor f => FunctorM' f where >> dist' :: Monad m => f (m a) -> m (f a) >> fmapM' :: Monad m => (a -> m b) -> f a -> m (f b) >> >> dist' = fmapM' id >> fmapM' f = dist' . fmap f >> >> -- for example >> instance FunctorM' [] where >> dist' = sequence >> fmapM' = mapM Does anyone else have any comments on the suggestions from Iavor and Thomas in this thread? I'm happy to make changes, but only if there's a concensus. The proposals so far seems to be 1) add dist method 2a) make Functor a superclass of FunctorM 2b) make Functor a *sub*class of FunctorM 2c) make Functor a subclass of Monad 2d) make Functor a superclass of Monad 3) rename FunctorM class to ForEach 4) rename FunctorM module to Control.Monad.FunctorM(?) (1) is easy and not controversial (but is 'dist' the best name?). AFAICT, 2a, 2b, 2c, and 2d have all been suggested (eg. the quoted message above suggests 2a, 2b and 2c). Perhaps some of the suggestions were typos, but at this point I'm a bit confused! Cheers, Simon

12 14