- Libraries - Haskell.org

Typo in HUnit cpp
by dons＠cse.unsw.edu.au 24 Aug '05

24 Aug '05

Looks like a typo in the HUnit code. Spotted by Stefan Wehr. Any objections? -- Don Index: Lang.lhs =================================================================== RCS file: /home/cvs/root/fptools/libraries/HUnit/Test/HUnit/Lang.lhs,v retrieving revision 1.2 diff -u -u -r1.2 Lang.lhs --- Lang.lhs 27 Mar 2004 14:26:07 -0000 1.2 +++ Lang.lhs 24 Aug 2005 08:06:46 -0000 @@ -18,7 +18,7 @@ ------- > import Data.List (isPrefixOf) -#if defined(__GLASGOW_HASKELL) || defined(__HUGS__) +#if defined(__GLASGOW_HASKELL__) || defined(__HUGS__) > import Control.Exception (try) #else > import System.IO.Error (ioeGetErrorString, try) @@ -61,7 +61,7 @@ > case r of Right () -> return Nothing > Left e -> return (Just (decode e)) > where -#if defined(__GLASGOW_HASKELL) || defined(__HUGS__) +#if defined(__GLASGOW_HASKELL__) || defined(__HUGS__) > decode e = let s0 = show e #else > decode e = let s0 = ioeGetErrorString e

1 0

Re: cabal design
by Frederik Eaton 23 Aug '05

23 Aug '05

On Mon, Aug 22, 2005 at 09:08:01AM -0700, Isaac Jones wrote: > Frederik Eaton <frederik(a)a5.repetae.net> writes: > > > If there have been a lot of discussions and decisions, I don't think > > that mailing list archives, or wherever the analysis is located, are a > > good repository for design documents. I believe (and I'm not saying > > you disagree at this point) that things which are planned and which we > > want people to potentially help out with should go on the wiki, along > > with their rationale. > > We wrote and maintained a proposal document. It's on the web page. Oh, this?: http://www.haskell.org/hawiki/LibraryInfrastructure Looks good. > (about adding a --package-conf= flag to cabal): > >> (snip) > >> >> In a way, the problem isn't "lack of support" but a different model of > >> >> finding packages... It's not like a compiler extension that one system > >> >> supports and one doesn't; this flag breaks abstraction between > >> >> compilers in a way that --in-place does not. I haven't heard any use > >> >> cases where --in-place won't work. > >> > > >> > Well, we're talking about two different features here. > >> > >> I'm talking about use cases, not features :) > > > > We're talking about two different use cases. > > > >> > I want to be able to specify an arbitrary location. You want to be > >> > able to specify the current working directory. Not the same thing, > >> > is it? I think it should be possible to specify an arbitrary > >> > location, at least for ghc. > >> > >> Since this breaks abstraction, I would prefer to avoid this until I > >> see a convincing use case. > > > > I thought I already gave one: http://toastball.net/toast/ > > Here's another: http://www.wigwam-framework.org/doc/overview.html > > Those aren't use cases. Can you please explain a situation where > --in-place doesn't work, and --package-conf= is required? Did you look at these tools? In order to use cabal packages with them, you'd have to be able to specify arbitrary package databases for each package. People have good reasons for doing so. Read the wigwam page especially. If cabal packages can't be installed in arbitrary locations, then not only will this be an serious pain in the ass for some special users - which should be enough of a reason on its own! - but it will rule out using Haskell in the server infrastructure of certain large software companies. I worked at Yahoo which doesn't use wigwam but uses something similar; I'm sure other places are moving or have moved in the same direction. Writing off these groups is surely a bad idea! Achieving this modularity with your --in-place suggestion, as I understand it, would require specifying a separate -package-conf option per package (or directory of packages, when that becomes allowed) per ghc invocation, at which point one would be hard pressed to call the things "package databases" since they will mostly contain one package each. Cabal would thus be forcing users to re-implement their own package database; plus, it would still require an interface to let them specify the package database locations, so nothing gained ... Note that any compiler that has a notion of packages is going to have a notion of a package database, whether it is a file or a directory or a search path of directories or a network server. It's where we go to find packages. All I'm saying is that this needs to be virtualizable. Cabal needs to let users specify it, whatever it is. > > But let's think about what you're saying. You don't want to break some > > abstractions in your implementation, so you're causing the abstraction > > that you are supposed to be providing your users with to break. > > Of course that's not what I'm saying. I still seen a use case where > --in-place won't work. > > Here's a general rule I follow when making decisions about cabal: If I > have two possible features, but only one use-case, and feature number > 1 covers that use-case just as well as feature number 2, and feature > number 1 maintains abstraction between compilers, whereas feature > number 2 breaks it, then I choose feature number 1. > > That is, try to find a way to solve the users' problem without > breaking the abstractions between compilers. To be sure, there is a trade-off between generality and practicality. However, I think you're failing to be general enough in the design of Cabal. Since it's going to be so widely used, we want to come up with an interface which won't have to change much, and this will require something which is more general than usual. However, there are valid use cases to support my argument for greater abstraction. Please let me know if there is still confusion over the use cases I've been presenting. > > We need to be able to deal with packages getting installed anywhere > > and everywhere and every which way. Everything about the > > installation of a package needs to be virtualizable. > > I disagree. When you write a common interface on top of multiple > implementations, you sometimes lose control over the details of the > implementations, but the interface remains useful because it is > consistent and nevertheless powerful. If you want control over every > aspect, then you can drop down to the implementations and use them > directly. So you're saying that someone who needs a particular level of abstraction from cabal should rewrite the build systems of all the packages that they intend to use, rather than asking Cabal to harbor a certain feature, if that feature is one which might only be supported when Cabal is used in conjunction with ghc? That's ridiculous. We have to look forwards, not backwards. We can't just restrict ourselves to the lowest common denominator of all compilers, or we won't go anywhere. Keep in mind that Cabal exists to serve its users, not the other way around. > > The package database should not be tied to the user or the system or > > the compiler version. > > There's really no way around that. Each compilers' binary format > differ. That's not what I meant. With ghc, there is a default package database which depends on the user and the compiler version. But you can specify a non-default location as well. Cabal should provide an interface which allows you to access this feature. Frederik -- http://ofb.net/~frederik/

3 5

cabal, ghc-pkg, PATH
by Frederik Eaton 22 Aug '05

22 Aug '05

Hi, Does cabal use the version of ghc and ghc-pkg from PATH? I have ones which are locally installed, and sometimes it seems like cabal is using the ones in /usr/bin/ instead. For instance, it is complaining about packages which are only visible to the versions installed in /usr/bin/. However, cabal wouldn't be messing up consistently since it shows the correct 'ghc' path for compilations, when I run it with '-v'. Thanks, Frederik -- http://ofb.net/~frederik/

2 2

cabal design
by Frederik Eaton 22 Aug '05

22 Aug '05

Hi, First of all I want to thank Isaac Jones for his work on Cabal. There are a few issues I would like to raise. 1) Cabal files can have different names, yet only one can exist in a directory. I've been told that the reason for the former is that Isaac wants to support building multiple packages in a directory, but currently the feature isn't implemented, so only one cabal file is allowed. Certainly, it would be a nice feature, but more importantly it seems that it would require some API changes or additions which should be made sooner rather than later. Is there a document describing how it would work? Is there a roadmap, a schedule for implementation? 2) As I have pointed out earlier, some aspects of the 'cabal' installation are specified at configure time, others (whether the package is --user or --global) must be specified at install time. In effect this means that the configuration is spread out over multiple commands, which is rather unsavory. 3) The way that a 'cabal' package with a 'configure' script should be built is not easy to determine. There are some very useful programs (http://toastball.net/toast/) which build and manage packages of all kinds automatically, by running 'configure' with a local prefix, etc. How should these tools be extended to work with 'cabal' packages? With some 'cabal' packages, the user is supposed to run 'configure' first, and then 'runhaskell Setup.hs'. With other 'cabal' packages, the user is supposed to just run 'runhaskell Setup.hs', and this will run 'configure' automatically. Is there a right way? Is there a way to distinguish the two types of packages automatically? 4) Cabal's inability to let users specify package.conf-s other than the user or global package.conf, and ghc's refusal (and that of other compilers) to let users specify paths for things via environment variables, not only complicates the task of tools like 'toast' (above) but makes it hard to create a "test" or otherwise isolated installation of a library or other package. For C libraries all I have to do is add, e.g., $HOME/.toast/armed/include to CPATH and everything works - whereas all of my haskell libraries would have to share the same user package.conf in order for using them to be manageable. To be sure, environment variables are not entirely necessary to do this, the relevant values could be explicitly passed between each stage of a build, but environment variables make the task much simpler. In any case, functional programming is about modularity. We should ask our compilers and packaging tools to support modularity as much as possible as well. To lag behind 'gcc' and 'autoconf' is not acceptable. 5) It seems that there should be a way to build multiple packages which depend on each other, in such a way as that the first package doesn't have to be installed for the second package to be built. In other words, perhaps something like a dummy installation as in #4 is called for. I have seen mention that support for building multiple packages is planned, but how? When? What stage of implementation are we in? 6) I think it should be easy to use 'cabal' for development; however, when I am building a package with multiple executables, every 'build' seems to re-link each executable, regardless of whether it needs re-linking or not, which is quite slow. Maybe this is a bug in ghc, but it would be good to fix it or work around it. In the same vein, it would be nice to have a standard command that invokes "runhaskell Setup.hs" but with fewer keystrokes. I'm not sure how much of this Isaac has planned out on his own and is busy implementing, vs. how much is waiting for someone to write a design document for. I probably don't have time to do much work on implementation, but I could be willing to, say, start a page on the wiki outlining what I think is involved, what the API should look like, etc., if this has not been done yet. Regards, Frederik

4 10

System.Process documentation bugs
by Nils Anders Danielsson 21 Aug '05

21 Aug '05

The documentation for System.Process.terminateProcess claims that under Un*x the SIGKILL signal is sent to the process, whereas the source uses SIGTERM. I would prefer if I could choose which signal to use. (The System.Posix interface cannot be used with ProcessHandles.) Furthermore the CVS log for base/cbits/runProcess.c states: getProcessExitCode(Unix): return some more useful values. If the process doesn't exist, return (Just ExitSuccess). This isn't ideal, but it's better than returning Nothing (which indicates the process is still running). This should be included in the documentation, or preferably a more detailed result should be returned. -- /NAD

1 0

RFC: Data.StringMap
by Adrian Hey 20 Aug '05

20 Aug '05

Hello, I've been playing about with a bit of applied AVLism to implement (hopefully) efficient String maps. I've posted what I've done so far here.. http://homepages.nildram.co.uk/~ahey/HLibs/Data.StringMap/ It's early days so it's a bit limited and hardly tested at all. I just want to ask peoples opinions on this before I go further. Like.. Does anybody object to me usurping the Data.StringMap slot in the hierarchical namespace? It seems to be vacant at the moment but maybe someone has other ideas about how this should be filled. Is anybody working on possible alternatives? If so it would be good to do some performance comparisons. I think the data structure I've used will turn out quite efficient, but there are other possibilities like using packed strings and/or hashing. Any suggestions or feature requests? Also, I'd be grateful someone could tell me what the data structure I've used is actually called :-) Thankyou -- Adrian Hey

4 7

Re: argument ordering (was: Re: Priority Queues, or lack thereof)
by Okasaki, C. DR EECS 19 Aug '05

19 Aug '05

Malcolm Wallace wrote: >> This style supports multiple operations nicely, especially with combined >> with the $ operator. > > But note that the version with $ is actually longer than the one > with nested parens! Only because I put in the third $, which wasn't necessary, and which most people using this style would probably omit. Without that $, they're the same length. And of course I could make the first one shorter by leaving out some of the whitespace, but I would never recommend that. Character counts are mostly irrelevant anyway -- what matters is ease of reading. To my eye, the version with the $ is slightly easier in this case, but opinions can certainly vary. I think the $ style becomes much easier to read as you (1) add more operations, and (2) start mixing operations (eg, some inserts and some deletes). For example, compare insert 1 $ delete 2 $ delete 3 $ insert 4 $ delete 5 someset and insert (delete (delete (insert (delete someset 5) 4) 3) 2) 1 In the latter style, how easy is it to tell whether 3 is being inserted or deleted? In the former style, it is obvious that 3 is being deleted. Of course, I will freely admit that such examples are fairly rare in real programs. > And where the operands are not statically known, > the different orderings do simply come down to > foldl/foldr preference: > > insert 1 $ insert 2 $ insert 3 $ someSet > == foldr insert someSet [1,2,3] > > insert (insert (insert someSet 3) 2) 1 > == foldl insert someSet [3,2,1] > > In some sense the foldl variant is more 'obvious' about the order in > which elements are actually inserted. Yes, I agree that the order of operations in the $ style is somewhat counter-intuitive (in exactly the same way that "foo . bar . baz" is). This rarely seems to be a problem in practice, however. The most common examples where I've seen this style used are things like initializing the dictionary of an interpreter with the "built-ins", in which case you know that none of the keys overlap so the order doesn't matter. -- Chris

1 0

Re: argument ordering (was: Re: Priority Queues, or lack thereof)
by Okasaki, C. DR EECS 19 Aug '05

19 Aug '05

In response to questions about why the convention of putting the data structure as the last argument... This style supports multiple operations nicely, especially with combined with the $ operator. For example, to insert 3 elements into a set, you can say insert 1 $ insert 2 $ insert 3 $ someSet (the last $ is optional). With the other argument ordering, you would say insert (insert (insert someSet 3) 2) 1 -- Chris

3 2

RE: cabal design
by Simon Peyton-Jones 19 Aug '05

19 Aug '05

| First of all I want to thank Isaac Jones for his work on Cabal. | | There are a few issues I would like to raise. Seconded -- Isaac you are doing a great job. As are lots of other contributors. One rather vexed question is the issue of whether a single program can contain two modules with the same name. Currently that is absolutely ruled out, and as a result packages are fundamentally non-modular: every package must use a distinct space in the global namespace. Simon Marlow and I have gradually become convinced that we have to fix this, and the only sensible way to fix it is to relax the language design so that a module name must be unique within its package (only) That means that module A.B.C could exist *both* in package P1 and in P2. And both packages could be linked into the same program. Some kind of 'grafting' or 'mounting' scheme would be needed to bring a package into the package namespace. One might say ghc -c Foo.hs -package gtk-2.3 Graphics.GTK to mount the gtk-2.3 package at Graphics.GTK in the name space. Outside the package one would need to import Graphics.GTK.M, but *within* the package one just imports M. That way the entire package can be mounted elsewhere in the namespace, if desired, without needing to change or recompile the package at all. The exact details of the mounting scheme, and whether it is done at build time, at install time, or at compilation time, or all of the above, are open to debate. We don't have a very fixed view. However, the fundamental thing GHC needs to do is to include the package name into the names of entities the package defines. That means that when compiling a module M you must say what package it is part of: ghc -C M.hs -package-name my-package-2.3 Then M.o will contain symbols like "my-package-2.3.M.f" etc. In effect, the "original name" of a function f in module M of package P is <P,M,f>. The purpose of this message is a) To advertise our willingness to implement this in GHC b) To ask whether doing so would be welcome, and if so to invite the Cabal afficionados to come up with a specific design for the programmer's interface c) To ask what the Hugs story might be. That is, are any of the Hugs folk willing to implement the necessary? The thing about (c) is that it'd be a Big Pity if new-style packages couldn't be used with Hugs because they don't obey the unique-module constraint. Ditto nhc. Simon

4 3

Priority Queues, or lack thereof
by Sebastian Sylvan 18 Aug '05

18 Aug '05

I've been puzzled by the lack of a priority queue implementation in the hierarchical libraries for some time. Sure, you could use a Data.Map as a priority queue, but something about having to pay O(log n) to find the smallest element bugs me. So, I decided to implement my own priority queue with optimal asymptotic time complexity. That is: insert : O(1) findMin : O(1) meld : O(1) deleteMin : O(log n) It's based heavily on the strategy detailed in the paper "Optimal Purely Functional Priority Queues" by Gerth StØlting Brodal and Chris Okasaki. This is asymptotically better than other, simpler, data structures, but the "constant factor" is likely very high (I haven't done any sort of serious benchmarking). I figured that if you have a small data set, the speed isn't going to matter much anyway, and if you have a large enough data set the asymptotically better data structure is faster. Anyway This was just something I threw together when I had some spare time. There may be misstakes in there, there's probably tons of room for improvement, but at least it's a priority queue! Download at: http://www.dtek.chalmers.se/~sylvan/PriorityQueue/ ----------------------------------------------------------------------------------------------------------- File Description ----------------------------------------------------------------------------------------------------------- PrimPQ.hs The internal workings of the skewed binomial tree PriorityQueue.hs The main priority queue module PriorityQueueTests.hs Some quickcheck properties ----------------------------------------------------------------------------------------------------------- /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862

3 4