- Libraries - Haskell.org

StateT example (an encore performance)
by Isaac Jones 16 Apr '05

16 Apr '05

I noticed a few bits lacking in the Control.Monad.State documentation. I think an example of using StateT to encapsulate IO would be a useful addition... In order to make StateT more interesting, the trick is to use a lift inside a function that returns StateT, so you can actually perform IO. I would guess that this is the kind of use case that most people would want to use StateT, but lift isn't mentioned in the docs. Also, the types of "runStateT" and "runState" are a little confusing, since they're actually field accessor functions, so I'd like to make a note on that. So how 'bout I add an example like the following to the State documentation? module Main where import Control.Monad.State type MyState a = StateT Int IO a stateFun :: MyState String stateFun = do modify (+100) liftIO (putStrLn "Hello!") return "foo" main = do (s, n) <- runStateT (stateFun >> stateFun) 0 putStrLn $ "n: " ++ (show n) ++ " s: " ++ s peace, isaac

2 2

Cabal Installing Executables
by Dominic Steinitz 16 Apr '05

16 Apr '05

When I run ./Setup install, the executables end up in /usr/local/bin which is not where I want them and not with the right permissions. Can someone tell me what I have to do to install the executables in the current directory or my home directory and also set the permissions (and ownership) to be that of the installer? Thanks, Dominic. Here's part of the cabal file: Executable: BERTest Main-Is: BERTest.hs Other-modules: Codec.ASN1, Codec.ASN1.BER and here's what happens to the executables in /usr/local/bin: -rwxr--r-- 1 root root 1317323 Apr 16 07:40 X509Example* -rwxr--r-- 1 root root 1555872 Apr 16 07:40 SymmetricTest* -rwxr--r-- 1 root root 1584127 Apr 16 07:40 RSAEncryptionExample* -rwxr--r-- 1 root root 1351135 Apr 16 07:40 PKCS8Example* -rwxr--r-- 1 root root 915278 Apr 16 07:40 BERTest*

1 0

Do you use GHC?
by Simon Peyton-Jones 15 Apr '05

15 Apr '05

Dear Haskell folk, PLEASE READ THIS IF YOU USE THE Glasgow Haskell Compiler (GHC). I virtually never send messages to overlapping sets of lists, but I'm doing so this time, because I'd really like to get to everyone who uses GHC. Here at GHC HQ, we are often asked how many people use GHC, and what kind of folk they are. Since GHC is free software, we have no clue. Download stats tell us a bit, but not much, because GHC gets out through a variety of other routes too (e.g. Debian). We also have little idea about which aspects of GHC are most valued, nor of what enhancements would be most sought after, or which platforms are most important to you. We hear quite a bit from the bleeding-edge folk who push the limits, but much less from people who just want to get the job done. Thus motivated, Tomasz Zielonka kindly put together a (WASH-powered) survey for us, which asks you to tell us a bit yourself and how you use GHC. We've had about 230 responses so far; thank you to those 230 folk. But I'm pretty certain there are more than 230 people in the world who use GHC! THIS MESSAGE IS TO ASK YOU TO TAKE 5 MINS TO COMPLETE THE SURVEY http://www.haskell.org/ghc/survey/start.cgi We'd like to hear from *absolutely everyone* who uses GHC: whether you are a first-year undergraduate or a famous professor; whether you use GHC for industrial applications or recreation; whether you use higher-rank polymorphism or have only just learned what functional programming is. Everyone! We'll use the information to guide our future priorities, and we'll publish some kind of summary of what we learn in due course. It's all anonymous, of course, unless you choose to say who you are. If you think it's appropriate, please circulate this announcement locally, e.g. to your students who may not be on the Haskell mailing list Many thanks Simon PJ and Simon Marlow

1 0

replacement for popen
by Uwe Schmidt 14 Apr '05

14 Apr '05

in the ghc-6.4 release the posix module is deprecated. I'm looking for a replacement and tried the System.Process functions. the following first try does not work for large files. it blocks if the file "long.file" does not fit into one os-buffer. then cat blocks and therefor waitForProcess blocks ------------------------------------ module Main where import IO import System import System.Process main :: IO () main = do (inpH, outH, errH, pH) <- runInteractiveProcess "cat" ["long.file"] Nothing Nothing hClose inpH res <- hGetContents outH errs <- hGetContents errH rc <- waitForProcess pH putStrLn ("rc: " ++ show rc) putStrLn ("stdout: " ++ res) putStrLn ("stderr: " ++ errs) exitWith rc ---------------------- the following version works fine, but it looks very much like a hack --------------------- module Main where import IO import System import System.Process main :: IO () main = do (inpH, outH, errH, pH) <- runInteractiveProcess "cat" ["long.filel"] Nothing Nothing hClose inpH res <- hGetContents outH errs <- hGetContents errH if (length $! res) == 0 -- hack !!! then return () else return () if (length $! errs) /= 0 -- hack !!! then return () else return () rc <- waitForProcess pH putStrLn ("rc: " ++ show rc) putStrLn ("stdout: " ++ res) putStrLn ("stderr: " ++ errs) exitWith rc ------------------------------------- is there a simple replacement for the popen using the System.Process module? uwe -- University of Applied Sciences, Wedel, Germany http://www.fh-wedel.de/~si/index.html mail:uwe@fh-wedel.de tel:++49-4103-8048-45

3 2

RE: import resolution (was RE: exposed packages and cabal depends)
by Simon Marlow 13 Apr '05

13 Apr '05

Think of it like this: a collection of Haskell source files often share common dependencies. Those dependencies include packages, but also things like what C libraries and header files are required by the code, and what extra GHC flags might be required to compile it. We find it convenient to put all this information in one place: the .cabal file. You can think of .cabal as part of the source if that helps. It really is part of the source - but implemented and specified as a layer on top of existing language and compiler technology, for convenience and so that we can share the tools. When all the dependencies are explicit, the code is portable. That's what you're arguing for - but we're already there. All you have to do is write a .cabal file, cut-and-paste a 3-line Setup.lhs file, and you're done. And for free, we'll throw in a multi-compiler, multi-platform build system and automated installation. But that's not all! Get Cabal, and later we'll also give you automated dependency download and installation, automated binary package generation in a variety of formats, automated publishing and lots more. Cheers, Simon

1 0

RE: import resolution (was RE: exposed packages and cabal depends)
by Simon Marlow 13 Apr '05

13 Apr '05

On 12 April 2005 19:58, S. Alexander Jacobson wrote: > My main goal here is to free the user from the hassle of manual > package installation. A module written in one location should "just > work" when moved to another. Rather than expoect modules to "just work" when moved from one location to another, I think it's more reasonable to expect *packages* to just work. This is the basis on which the package system and Cabal is built. Build and run dependencies are more than just the modules that the source code imports. Take a look at what's in a Cabal description: you'd need to put most of that in the source code to make portable modules. It's not practical, and I argue that the source code is the wrong place for that stuff. > And, if the meaning of module names is parametrized by package then > package names should be part of import statements. If packages are > purely adminisistrative, then they shouldn't. Yes, modules are parameterised by package, but no, I don't agree that packages should be specified in the source code. You really don't want to have to write import base>=1.0 Data.List all over the place. Or maybe you do? > PS In my last few posts I assumed you had rejected removing the > overlap restriction because that is what I interperted you to have > said e.g. here: > > We're not going to support this, at least for the forseeable > future. It's a pretty big change: every entity in the program > becomes parameterised by the package name as well as the module > name, because module names can overlap. > > http://www.haskell.org//pipermail/haskell/2005-March/015597.html Ok, I was perhaps a little sronger than I intended in that message. The overlap restriction is there for engineering reasons, it's not a fundamental problem, and one day it might be lifted. FWIW, I think we all agree that it sucks. > And here > > Also, the Haskell module hierarchy is supposed to reflect > functionality, whereas package names are purely administrative. > This is a reason for not including package names in source code. > > http://www.haskell.org//pipermail/libraries/2005-April/003513.html > > Did you change your mind or am I misinterpreting? My position on that hasn't changed. Cheers, Simon

3 2

RE: replacement for popen
by Simon Marlow 13 Apr '05

13 Apr '05

On 12 April 2005 16:38, David Brown wrote: > On Tue, 12 Apr 2005 14:22:00 +0200, Uwe Schmidt <uwe(a)fh-wedel.de> > wrote: > >> in the ghc-6.4 release the posix module is deprecated. > > I assume you're referring to popen not being available. I hope that > all of System.Posix isn't being deprecated. No, only the old Posix library in hslibs is deprecated. System.Posix is the replacement. Cheers, Simon

1 0

RE: replacement for popen
by Simon Marlow 13 Apr '05

13 Apr '05

On 13 April 2005 07:53, Uwe Schmidt wrote: > I tried > >> forkIO(evaluate(length res) >> return ()) > > but this version again blocks. You are compiling with -threaded, right? It's needed for non-blocking waitForProcess. The docs do mention this. Cheers, Simon

1 0

RE: replacement for popen
by Simon Marlow 13 Apr '05

13 Apr '05

On 12 April 2005 13:22, Uwe Schmidt wrote: > in the ghc-6.4 release the posix module is deprecated. > I'm looking for a replacement and tried the > System.Process functions. the following first try > does not work for large files. it blocks if the > file "long.file" does not fit into one os-buffer. > then cat blocks and therefor waitForProcess blocks > > ------------------------------------ > > module Main where > > import IO > import System > import System.Process > > main :: IO () > main = do > (inpH, outH, errH, pH) <- runInteractiveProcess "cat" > ["long.file"] Nothing Nothing hClose inpH > res <- hGetContents outH > errs <- hGetContents errH > > rc <- waitForProcess pH > > putStrLn ("rc: " ++ show rc) > putStrLn ("stdout: " ++ res) > putStrLn ("stderr: " ++ errs) > exitWith rc > > ---------------------- > > the following version works fine, but it looks very much like a hack > > --------------------- > > module Main where > > import IO > import System > import System.Process > > main :: IO () > main = do > (inpH, outH, errH, pH) <- runInteractiveProcess "cat" > ["long.filel"] Nothing Nothing hClose inpH > res <- hGetContents outH > errs <- hGetContents errH > > if (length $! res) == 0 -- hack !!! > then return () > else return () > > if (length $! errs) /= 0 -- hack !!! > then return () > else return () > > rc <- waitForProcess pH > > putStrLn ("rc: " ++ show rc) > putStrLn ("stdout: " ++ res) > putStrLn ("stderr: " ++ errs) > exitWith rc If you really must use hGetContents, then the hack above is necessary: you have to force the output strings before waiting for the process to terminate. This would be slightly cleaner: > res <- hGetContents outH > errs <- hGetContents errH > forkIO (evaluate (length res)) > forkIO (evaluate (length errs)) which avoids blocking the main thread, but ensures that all the data gets pulled as it becomes available. It looks like the same hack would be required with the old POpen interface too - if not, can you show an example of something that works with popen but not with System.Process? Cheers, Simon

2 1

RE: Module Holism (was RE: exposed packages and cabal depends)
by Simon Marlow 12 Apr '05

12 Apr '05

On 12 April 2005 01:28, S. Alexander Jacobson wrote: > On Mon, 11 Apr 2005, Simon Marlow wrote: >>> The problem is, we don't want to import two modules, only to >>> discover that somewhere in their dependencies they each use the >>> same module name to refer to conflicting module implementations. >> >> This is the problem that the overlap restriction leads to, yes. > > No, you have this problem even with atomic modules. It is a result > simply of not allowing two modules to share the same name in the same > program and has nothing to do with package overlap. When I say "overlap restriction" I mean the restriction that prevents having two modules with the same name in the same program. >>> Therefore, we really want to say that no two modules we might want >>> to import into our programs (either directly or indirectly) should >>> share the same name. And, in particular, we don't want a packaging >>> or versioning system that encourages it! >> >> No, you've drawn a bogus conclusion again. We most definitely want >> the ability to choose between multiple instances of a particular >> module in programs. > > My point is that the choice of instance should be made at > compile/build/run times and not at packaging time. Dependencies must be expressed at package time, otherwise they are untracked dependencies. Right? A package must state that it needs implementation P of module M rather than implementation Q, otherwise there's a chance that the guy building the package will get the wrong one. Build-depends lets you select an implementation from a range (currently it's just a version range, but we could make the language more expressive and include alternatives, I doubt it would be that useful in practice, though). So dependencies are selected at compile time. Selecting dependencies at run-time (I assume this is what you mean by late binding) is another kettle of fish: at least, it would mean that GHC couldn't do its aggressive cross-module optimisation against the library that you're late-binding to. But I think it's worthwhile investigating to what extent this is possible, so that we can have upgradable shared libraries. >> For example, if I have two versions of a package installed, >> say P-1 and P-2, I want to be able to compile my old code that >> depends on P-1 while still being able to write new code against P-2. >> And I want to be able to use other packages that still depend, for >> the time being, on P-1. When P-3 comes out, I don't want to be >> forced to uninstall P-1 and P-2 before I can use it. > > Now what happens when you want to use one package that depends on P-1 > and another that depends on P-2 at the same time? Of course, you can't do that. That's what the "overlap restriction" prevents. As I've explained. [ the next three paragraphs, which I deleted, all complain about scenarios which we can't handle because of the overlap restriction. I don't think I need to comment any further. ] [ more stuff deleted, this thread is too long already ] Cheers, Simon

3 2