August 2005 - Libraries

external core
by John Meacham 22 Mar '06

22 Mar '06

Now, the external core feature of ghc is great, but it is not utilized very much. The main reason I think is that there is a large barrier to entry in writing something that uses it since you need to parse/generate it. It would be nice if there were a standard library that came with ghc (or cabalized and portable even better) that could parse and pretty print external core. ideally, one could write a simple pass-through core processor that interacts with ghc in a single line and someone working on a new optimization need only worry about that. Also, it would make it very easy for jhc to generate and parse ghc core files (always an ulterior motive). I wanted to use jhcs front end to generate ghc core so I could get a true measure of the difference in just their back-end performance without taking into account ghc's superior high-level optimizations. In any case. I think all the code is out there in ghc and it just needs to be separated and cabalized. I know there was talk of creating a ghc internals library, but it would be nice if this code were portable and independent. John -- John Meacham - ⑆repetae.net⑆john⑈

3 4

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

cabal configure screw-up
by Frederik Eaton 30 Aug '05

30 Aug '05

Hi Ross, I'm experiencing the following problem. I'm trying to use a 'configure' script which is not a 'sh' script, but Cabal assumes that all 'configure' scripts are 'sh' scripts regardless of what '#!' line they start with. Isaac says this is your doing. What is the reason for it? The lines are in cabal/Distribution/Simple.hs: where defaultPostConf :: Args -> ConfigFlags -> LocalBuildInfo -> IO ExitCode defaultPostConf args flags lbi = do let prefix_opt pref opts = ("--prefix=" ++ pref) : opts confExists <- doesFileExist "configure" if confExists then do rawSystemVerbose (configVerbose flags) "sh" ("configure" : maybe id prefix_opt (configPrefix flags) args) return () else no_extra_flags args return ExitSuccess Note that if a file doesn't have any '#!' line at all then (at least on my system) it is executed with /bin/sh. So when you run something explicitly with /bin/sh, you are ONLY affecting things which explicitly ask to be run with something other than /bin/sh. Isaac refuses to let me fix this until you speak up because he's afraid it might break the fptools build, so, ... Frederik -- http://ofb.net/~frederik/

8 17

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

24 Aug '05

David Roundy wrote: >> 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 > > With this ordering, couldn't one simply write > > someSet `insert` 3 `insert` 2 `insert` 1 > > ? Sure, although I'll admit that I have an aversion to the backquote style of infix operators. The bigger problem with this style is what to do about non-binary operations. For example, insert for a dictionary takes three arguments. So you could write insert 1 a $ insert 2 b $ insert 3 c dict but not dict `insert` 1 a `insert` 2 b `insert' 3 c Of course, you could potentially package some arguments in a tuple dict `insert` (1,a) `insert` (2,b) `insert` (3,c) but having some arguments in tuples has its own problems. -- Chris

7 6

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