April 2005 - Libraries

Data.Map documentation lacks a bit of precision
by Jesper Louis Andersen 05 Apr '05

05 Apr '05

I am not sure this is the correct mailing list. But the old Data.FiniteMap implementation states for the function ``addToFM'' (in the haddock documentation): Adds an element to a FiniteMap. Any previous mapping with the same key is overwritten. Whereas the equivalent ``insert'' in the new Data.Map module States: O(log n). Insert a new key and value in the map. --- I think it is good that there now is a running time asymptotic bound, but I do not know what happens if the (key, value) pair is already there. There is no information about this in the haddock documentation at all. It could either overwrite silently, or it could raise some kind of error. Both options are plausible, since one could just use ``Data.Map.adjust'' like: f :: Ord k -> k -> a -> Map k a -> Map k a f k a fm = Data.Map.adjust (\_ -> a) k fm And gain the explicit behaviour. I do not currently have a GHC 6.4 installed here, so I cannot test this behaviour, but some code I am working on needs to be fairly compatible. Therefore we have a layer on top of Data.FiniteMap which implements the new map structure. This difference just caught my eye. It also makes it rather hard to update the documentation myself and provide a patch. Where is the official repository located? -- jlouis

3 2

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

04 Apr '05

On 01 April 2005 07:31, S. Alexander Jacobson wrote: > I want to allow the user to know exactly which implementations they > are using when they import a module-id while at the same time giving > them maximal choice of implementations to use. Everything else here > is just details. I'll comment on the overall goal then: I'm in complete agreement that requiring dependencies to be specified is a good thing. For some reason you want to do this with language extensions or compiler extensions rather than using Cabal - but this is one of the things that we expected Cabal to address, which is why you're getting some pushback. I'm interested in why you're avoiding Cabal: if you could elaborate on that (perhaps in a separate thread) we might be able to make some improvements. You've identified a few problems with the current system: (a) some packages are exposed by default, which leads to people being able to write code without knowing (or needing to know) which packages they're using, resulting in untracked dependencies. I think this is a compromise, and I think it's a good one. Being able to just import any of the hierarchical modules I have installed on my system without having to give a -package flag is really useful (don't touch that keyboard! I haven't finished yet :-). If I decide that I want to give the code to someone else, then the dependencies become important. This is where Cabal comes in: if you're not already using Cabal as a plain build system, then you probably want to use it to ship the code to someone else anyway. And at that point you're forced to enumerate the dependencies. Sure, we currently have a problem that the dependencies in Cabal are unchecked, but that's just a bug. (I'm coming around to Isaac's earlier suggestion of -fhide-all-packages, actually). (b) dependencies aren't specified per-module. I can't express that I expect module M to come from package P. I see this as documentation, but I agree it's useful documentation, and it would be even more useful if it were automatically checked. I don't see any fundamental problem with adding this to Cabal. >>> * Oh, we made local changes too!? What were they? > > Does Cabal/Hackage notify the user of differences between official > packages and local versions? If not, this is another untracked > dependency. If you modify a package, you're required to give it a new version number and/or a different package name. No this isn't checked, but it could be (calculating a hash of the external interface of the package, for example). >>> * But what happens if I don't have root/admin on the target >>> machine? [...] >>> * Oh, this package conflicts with something already installed? >>> [etc.] > > Are some packages allowed to modify the haskell implementation itself? > More risk of untracked dependencies. Nope, they aren't (fortunately). This is one reason we removed the extra_ghc_options field that used to be in the package config. Cheers, Simon

4 3

ANN: SerTH - A Binary serialization layer for Haskell
by Einar Karttunen 02 Apr '05

02 Apr '05

Hello I have developed a small library for serializing Haskell datatypes in a binary form. SerTH offers the following features: * Binary serialization * Using template haskell to derive serializer interfaces for each type wanted * Support for cyclic structures * Supports user defined serializers for types (just define the instance) * Support for a limited kind of dynamically types serialization/deserialization * BSD license But has the following limitations: - Only serializers for haskell98 datatypes can be inferred (template haskell does not support reification of other types) - Serialization format is not compressed - Currently only works with GHC-6.4 http://www.cs.helsinki.fi/u/ekarttun/SerTH/ - Einar Karttunen

1 0

Typo in Control.Monad.ST documentation
by John DeTreville 01 Apr '05

01 Apr '05

The Control.Monad.ST documentation says: "This library provides support for strict state threads, as described in the PLDI '94 paper by John Launchbury and Simon Peyton Jones Lazy State Threads." The paper's proper name is "Lazy Functional State Threads." Cheers, John

1 0

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