March 2005 - Libraries

Trie implementation
by Keith Wansbrough 10 Mar '06

10 Mar '06

Hi... I was writing some code yesterday to walk over a directory tree, and needed a Trie. Not seeing one around, I wrote a basic implementation of the functions I needed (attached below). Has anyone else done this? Should I polish it up and offer it for inclusion in Data? --KW 8-)

7 8

NewBinary Library
by Peter Simons 05 May '05

05 May '05

Hi, the NewBinary library used to be available via Darcs at this place: http://www.n-heptane.com/nhlabca/repos/NewBinary It appears, though, that this repository has vanished. Does anyone know what happened? Is anyone aware of the new home of the library? Peter

2 1

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

Relax the Either monad
by Yitzchak Gale 28 Mar '05

28 Mar '05

An instance of Monad (Either a) is defined in Control.Monad.Error. Unfortunately, that instance requires the type "a" to be an instance of Error. In fact, using Either for exception handling is only a special case. The Either monad is more generally useful for any complex calculation that needs to exit in the middle and return a value, including multi-level exit. (And no thank you, I would not like to obfuscate my code by using Cont and callCC for that. The Either monad is simple and clean.) It is annoying to work around this problem, since one often has to import Control.Monad.Error. Could this restriction be removed? The Error instance is not used, except to define fail. I don't think it is really important to have a Monad instance where fail references the Error instance; throwError is much more clear. But if others disagree, perhaps a synonym could be used for Either in the context of exceptions. Anyway the namespace there is a bit of a mess; one expects Error to be the non-transforming version of ErrorT, but it is not. How about Throws or Thrown, so I can say: myFun :: a -> b -> c -> Error1 `Thrown` Error2 `Thrown` Error3 `Thrown` ReturnType -Yitz

3 3