October 2008 - Haskell-Cafe

daemon process
by Rouan van Dalen 21 Oct '08

21 Oct '08

Hi Everyone. I have been learning Haskell the past few months and there are tons of things I still don't understand :) I would like to write a very very simple haskell daemon that disconnects itself from the terminal and sists in the background doing something. What is the easiest way to go about this. I have tried several things but can't seem to get the process disconnected from the terminal. Thanks in advance Rouan Send instant messages to your online friends http://uk.messenger.yahoo.com

2 1

File handles and pipes
by Stephen Hicks 20 Oct '08

20 Oct '08

Hi, I'm trying to understand how to get pipes working in Haskell, in particular with the revamped System.Process (though I've tried similar experiments with System.Posix.IO and Control.Concurrent). Specifically I'm trying to concatenate the output of two system calls into the input of a third. The following code does not get the job done: > import Data.Maybe ( fromJust ) > import System.IO > import System.Process > sink :: String -> IO (Handle,ProcessHandle) > sink s = do let p = (shell s) { std_in = CreatePipe } > (mh, _, _, ph) <- createProcess p > return (fromJust mh,ph) > source :: String -> Handle -> IO () > source s h = do let p = (shell s) { std_out = UseHandle h, > close_fds = False } > (_, _, _, ph) <- createProcess p > waitForProcess ph > return () > main :: IO () > main = do (h,p) <- sink "sort" > source "df" h > source "df -h" h > waitForProcess p > return () When I run this, I see that the filehandle h is closed after the first df, so the output only has one of the two df's included in it. I tried also System.Posix.IO (createPipe, fdToHandle, dup) to make this work, but that gave a "read failed" error. Is there any way to get this done...? In general, given a handful of system calls (and/or read/write handles), is there a way to combine them all together? (I also tried using forkIO on my own function pipe :: [Handle] -> Handle -> IO (), which does what you'd expect given multiple read handles and a single write handle, but couldn't get any output from that at all...) Any help is appreciated, steve

4 4

Re: [Haskell] Probably a trivial thing for people knowing Haskell
by Chris Eidhof 20 Oct '08

20 Oct '08

I think it might be more appropriate to move this discussion to haskell-cafe. On 19 okt 2008, at 17:24, Friedrich wrote: >> Learn to love types: one of the neat things about Haskell is that if >> you can write down the type of a function then you have usually done >> 90% of the work of writing the code for it. > Well I disagree. But that's another story. Well, it's definitely not true when you're starting out with Haskell. The thing is: once you start to think in types it does work like this. You just think: what do I need as my input and what's my output. That's what you write down as your type and you're almost done! It's very similar to test-driven development; the point with TDD is not so much about making sure your program is correct: the big win (for me) is that it helps you think about the design of your program. The same holds for types. > > >> Another is that in >> general, if you can't express the type of a function, it means you >> haven't thought through what you're trying to do. > > No that's not true. The use implies that. However I'm not advice > resistant and will see if I use types. But IMHO that's should be job > of the environment to figure out correctly and most of the time > Haskell does "guess" right. And I surely can ask for the types. I agree. However, sometimes, when things get really complex, you can't figure out a way to write down the code. That's when it can be handy to start out from the types and slowly work towards the definition. At first, you'll think that types are there to make your life harder. After a while, you'll start to love them and to be honest: I feel quite uncomfortable programming in an untyped language these days ;). -chris

3 2

Haskell syntax inside QuasiQuote
by Reiner Pope 20 Oct '08

20 Oct '08

Hi, I have written a toy fixed-length-vector quasiquoter, so that you can write [$vec|1,2|] which has its type inferred as (Vec (S (S Z))) and you can write mkVec :: Double -> Vec (S (S (S Z))) mkVec x = [$vec|1,2,x|] However, these above examples essentially demonstrate the entire syntax it supports: number literals, and anti-quoted variables. I would like to extend my quasiquoter to support Haskell's full expression syntax, so that we can write, for example, mkVec2 x = [$vec| if x > 5 then sin x else cos x |] Is there a simple way to do this, i.e. using existing libraries? What I need is a Haskell expression parser which outputs values of type Language.Haskell.TH.Syntax.QExp, but I can't see one available in the TH libraries, or in the haskell-src(-exts) libraries. Thoughts? Cheers, Reiner

1 0

Is there already an abstraction for this?
by Jeremy Shaw 20 Oct '08

20 Oct '08

Hello, I am trying to figure out if there is an existing abstraction I am missing here. I have an expression data-type: > data Expr > = Quotient Expr Expr > | Product Expr Expr > | Sum Expr Expr > | Difference Expr Expr > | Lit Double > | Var Char > deriving (Eq, Ord, Data, Typeable, Read, Show) > And I want to write a function that will take an expression and automatically apply the identity laws to simplify the expression. The basic identity laws are: a + 0 = a a * 1 = a I can implement these with some 'sugar' as: > identity (Sum (Lit 0) a) = a > identity (Sum a (Lit 0)) = a > identity (Difference a (Lit 0)) = a > identity (Product a (Lit 1)) = a > identity (Product (Lit 1) a) = a > identity (Quotient a (Lit 1)) = a > identity a = a This works fine when the identity only needs to be applied to the root of the expression tree: *Main> ppExpr $ identity (expr "1 + 0") 1 But for more complicated trees it does not fully apply the identity laws: *Main> ppExpr $ identity (expr "0 + (0 + 0) + (0 + 0)") ((0 + 0) + (0 + 0)) What we need to do is first apply the identity function to the children, and then apply them to the parent of the updated children. A first attempt would be to extend the identity function like this: > identity (Sum a b) = identity (Sum (identity a) (identity b)) However, that will not terminate because that same case will keep matching over and over. Another approach is to have two mutually recursive functions like: > identity' (Sum (Lit 0) a) = identityRec a > identity' (Sum a (Lit 0)) = identityRec a > identity' a = a > identityRec (Sum a b) = identity' (Sum (identity' a) (identity' b)) This prevents non-termination, but you have to be careful about calling identity' vs identityRec or you will either re-introduce non-termination, or you may not fully apply the identity laws. Another option to create a helper function like: > -- |Deep map of an expression. > eMap :: (Expr -> Expr) -> Expr -> Expr > eMap f (Sum a b) = f (Sum (eMap f a) (eMap f b)) > eMap f (Difference a b) = f (Difference (eMap f a) (eMap f b)) > eMap f (Product a b) = f (Product (eMap f a) (eMap f b)) > eMap f (Quotient a b) = f (Quotient (eMap f a) (eMap f b)) > eMap f (Var v) = f (Var v) > eMap f (Lit i) = f (Lit i) Now we can easily apply the identity law recursively like: > deepIdentity :: Expr -> Expr > deepIdentity = eMap identity *Main> ppExpr (deepIdentity (expr "0 + (0 + 0) + (0 + 0)")) 0 Sweet! But, having to write eMap out by hand like that somehow feels wrong -- as if I am missing some additional abstraction. In some respects eMap is like a Functor, but not quite. I expect there is a way to implement eMap using Data.Generics, which is perhaps better, but I still feel like that is missing something? Anyway, I just thought I would ask in case someone recognized this pattern and could point me in the right direction. I have attached a working example program you can play with. I would also be interested in alternative approaches besides the ones I outlined. thanks! j. >{-# LANGUAGE DeriveDataTypeable #-} > > import Control.Applicative (Applicative((<*>), pure), (*>), (<*)) > import Control.Monad (ap) > import Data.Generics (Typeable, Data) > import Data.List (isSuffixOf) > import Text.ParserCombinators.Parsec ((<|>)) > import qualified Text.ParserCombinators.Parsec as P > import qualified Text.ParserCombinators.Parsec.Expr as P > import Text.PrettyPrint.HughesPJ ((<+>)) > import qualified Text.PrettyPrint.HughesPJ as H > import Prelude hiding (sum, product) > > data Expr > = Quotient Expr Expr > | Product Expr Expr > | Sum Expr Expr > | Difference Expr Expr > | Lit Double > | Var Char > deriving (Eq, Ord, Data, Typeable, Read, Show) > > instance Applicative (P.GenParser token state) where > pure = return > (<*>) = ap > > parseExpr :: P.GenParser Char st Expr > parseExpr = P.buildExpressionParser optable (lit <|> var <|> parenExpr) > where > parenExpr = > (P.char '(' >> P.skipMany P.space) *> parseExpr <* (P.char ')' >> P.skipMany P.space) > optable = > [ [ P.Infix (P.char '/' >> P.skipMany P.space >> return Quotient) P.AssocLeft ] > , [ P.Infix (P.char '*' >> P.skipMany P.space >> return Product) P.AssocRight ] > , [ P.Infix (P.char '+' >> P.skipMany P.space >> return Sum) P.AssocRight ] > , [ P.Infix (P.char '-' >> P.skipMany P.space >> return Difference) P.AssocLeft ] > ] > lit = > do d <- P.try (P.many1 $ P.oneOf ('-' : '.' : ['0'..'9'])) > P.skipMany P.space > return (Lit (read d)) > var = > do sign <- (P.char '-' >> return (\x -> (Product (Lit (-1)) x))) <|> (return id) > v <- (P.upper <|> P.lower) > P.skipMany P.space > return (sign (Var v)) > > expr :: String -> Expr > expr str = either (error .show) id (P.parse parseExpr str str) > > ppExpr :: Expr -> H.Doc > ppExpr (Lit i) = H.text (let f s = if isSuffixOf ".0" s then init(init s) else s in f $ show i) > ppExpr (Var v) = H.char v > ppExpr (Quotient x y) = H.parens (ppExpr x <+> H.char '/' <+> ppExpr y) > ppExpr (Product x y) = H.parens (ppExpr x <+> H.char '*' <+> ppExpr y) > ppExpr (Sum x y) = H.parens (ppExpr x <+> H.char '+' <+> ppExpr y) > ppExpr (Difference x y) = H.parens (ppExpr x <+> H.char '-' <+> ppExpr y) > -- |Deep map of an expression. > eMap :: (Expr -> Expr) -> Expr -> Expr > eMap f (Sum a b) = f (Sum (eMap f a) (eMap f b)) > eMap f (Difference a b) = f (Difference (eMap f a) (eMap f b)) > eMap f (Product a b) = f (Product (eMap f a) (eMap f b)) > eMap f (Quotient a b) = f (Quotient (eMap f a) (eMap f b)) > eMap f (Var v) = f (Var v) > eMap f (Lit i) = f (Lit i) > identity (Sum (Lit 0) a) = a > identity (Sum a (Lit 0)) = a > identity (Difference a (Lit 0)) = a > identity (Product a (Lit 1)) = a > identity (Product (Lit 1) a) = a > identity (Quotient a (Lit 1)) = a > identity a = a > deepIdentity :: Expr -> Expr > deepIdentity = eMap identity > test :: IO () > test = > do print (ppExpr (deepIdentity (expr "1 + 2"))) > print (ppExpr (deepIdentity (expr "0 + (0 + 0) + (0 + 0)")))

11 12

is 256M RAM insufficient for a 20 million element Int/Int map?
by Thomas Hartman 20 Oct '08

20 Oct '08

{-# LANGUAGE BangPatterns #-} import qualified Data.Map as M import Debug.Trace {- I'm trying to run a HAppS web site with a large amount of data: stress testing happstutorial.com. Well, 20 million records doesn't sound that large by today's standards, but anyway that's my goal for now. I have a standard Data.Map.Map as the base structure for one of my macid data tables (jobs), but I noticed something that is probably causing problems for me. Even a simple 20 million record with int/int key values causes an out of memory error for me in ghci, on a computer with 256M of ram. I'm wondering if there is a data structure that might be more suitable for large recordsets. Or do you just have to use a database, or some sort of file-based serialization, once your records are in the millions? Or is this some weird subtlety of lazy evalution, or some other haskell gotcha? -} size = 2 * 10^7 -- out of memory error t = (M.! size) . myFromList . map (\i->(i,i)) $ [1..size] -- Lists are no problem {- *Main> :! time ghc -e tL testMap.hs (20000000,20000000) 3.38user 0.09system 0:03.53elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k -} tL = (!! (size-1)) . map (\i->(i,i)) $ [1..size] t2 = (M.fromList . map (\i->(i,i)) $ [1..10] ) M.\\ (M.fromList . map (\i->(i,i)) $ [6..15]) -- does this evaluate all of list l, or just whnf? myFromList (!l) = M.fromList l

11 18

Re: [Haskell-cafe] is 256M RAM insufficient for a 20 millionelement Int/Int map?
by Max Bolingbroke 19 Oct '08

19 Oct '08

2008/10/20 Don Stewart <dons(a)galois.com>: > claus.reinke: >> Ideally, I'd just like to indicate the strictness in the types (hint to ghc >> hackers: 'Data.Map.Map Int !Int' and '[!a]' would really be useful!-), > In general, being able to specialise polymorphic structures so they look like unpacked > monomorphic ones would be awesome. > > (!Int, !Bool) -> (,) {-# UNPACK #-}!Int {-# UNPACK #-}!Bool I spent some time thinking about how one might actually go about implementing this in GHC today, and came to the conclusion that it interacts far too badly with separate compilation. In an ideal world, you know which specialisations to generate for the data structure when compiling it in the first place. You would then of course generate the appropriate specialisations for all subsequent polymorphic function definitions that use the speciliased type ((,), IntMap or whatever), so you don't lose the ability to apply your unpacked version to a function of type like (a, b) -> a - see http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.55.8984 that Claus pointed to. But we don't have that information yet at the point where we compile a data definition... The CLR has a similar problem but gets away with it because it has a JIT compiler that can see the original definitions of classes / methods and instantiate them at the necessary types at runtime (see http://research.microsoft.com/~akenn/generics/space2004generics.pdf) One possible approach for GHC would be to generate all possible specializations for a datatype + functions when compiling a module. This sounds bad, but actually you only need to cater for at most three unboxed field sizes: 1) 32 bit (Int#, Word#, Float#, Addr#) 2) 64 bit (Int64#, Word64#) 3) Usually 64 bit (Double#) Of course, if you have a type like (,,,) with 4 type arguments you still have to potentially generate 3^4 specialisations (and corresponding functions!) so this /can/ get bad quickly :-). This is also sort of a hack, in that it crucially relies on the fact that unboxed tuples don't really make sense as type arguments yet. This is because types like (# Int, Bool #) -> Int are rejected by the compiler - unboxed tuples can only occur on the right of function arrows. However, this is just a technical limitation, and were it to be lifted it might make sense to be able to instantiate data types at unboxed tuple types, blowing this scheme out of the water. You could also export the entire definition of functions+data structures you might need to specialise across module boundaries, and generate specialisations where they are needed, but this can lead to redundant code generation with diamond dependencies (see the Syme/Kennedy paper - though I don't think their problem with redundant type descriptors applies to Haskell, making it easier to apply) and would bloat .hi files. This might still be the best way to go about it, should someone choose to implement it,. A further alternative would be to just compile every function once, but pass something like a dictionary to every function to tell it how to handle its own arguments (how much stuff to pop off the stack etc). Clean ,but the huge runtime overhead of this approach kind of defeats the point of using unboxed types in the first place. A final alternative would be to somehow recompile a module with the desired instantiation if it turned out not to contain it. But this could potentially lead to greatly increased compile times... So, I can't really see a clean way to go about this without going the whole hog and turning GHC into a whole-program compiler :-) Cheers, Max

1 0

Questions for Free!
by Creighton Hogg 19 Oct '08

19 Oct '08

Hello Haskellers, So I have a bit of a follow up question after reading Theorems For Free! this weekend. There's a throw away comment near the beginning about how you can recast the results into category theoretic form, but using lax natural transformations. Now I'm assuming this means a natural transformation but where the "naturality" square holds only up to isomorphism instead of equality, but is that correct? Also, why would you need such a condition? Cheers, Creighton

1 0

Error building GHC 6.8.3: "version of ../../compiler/stage1/ghc-inplace could not be determined"
by Devin Mullins 19 Oct '08

19 Oct '08

Hi, I'm trying to build 6.8.3 on Linux PowerPC, based on an old binary of 6.4 (latest build for this arch that I found). stage1 seems to have built, but from there, building libraries almost immediately fails: > make -C libraries all > make[1]: Entering directory `/home/twifkak/arch/ghc/src/ghc-6.8.3/libraries' > rm -f -f stamp/configure.library.*.base base/unbuildable > ( cd base && setup/Setup configure \ > --enable-library-profiling --enable-split-objs \ > --prefix=/NONEXISTANT \ > --bindir=/NONEXISTANT \ > --libdir=/NONEXISTANT \ > --libsubdir='$pkgid' \ > --libexecdir=/NONEXISTANT \ > --datadir=/NONEXISTANT \ > --docdir=/NONEXISTANT \ > --htmldir=/NONEXISTANT \ > --interfacedir=/NONEXISTANT \ > --with-compiler=../../compiler/stage1/ghc-inplace \ > --with-hc-pkg=../../utils/ghc-pkg/ghc-pkg-inplace \ > --with-hsc2hs=../../utils/hsc2hs/hsc2hs-inplace \ > --with-ld=/usr/bin/ld \ > --haddock-options="--use-contents=../index.html \ > --use-index=../doc-index.html" \ > --configure-option='--prefix=/usr' --configure-option='CFLAGS=-mtune=powerpc -O2 -pipe -mpowerpc-gfxopt' \ > --configure-option=--with-cc=gcc ) \ > && touch stamp/configure.library.build-profiling-splitting.base || touch base/unbuildable > Configuring base-3.0.2.0... > Setup: ghc version >=6.2 is required but the version of ../../compiler/stage1/ghc-inplace could not be determined. > if ifBuildable/ifBuildable base; then \ > cd base && \ > cmp -s ../Makefile.local Makefile.local || cp ../Makefile.local .; \ > mv GNUmakefile GNUmakefile.tmp; \ > setup/Setup makefile -f GNUmakefile; \ > cmp -s GNUmakefile GNUmakefile.tmp && mv GNUmakefile.tmp GNUmakefile; \ > make -wr && \ > setup/Setup register --inplace; \ > fi > mv: cannot stat `GNUmakefile': No such file or directory > Setup: error reading dist/setup-config; run "setup configure" command? > > make[2]: Entering directory `/home/twifkak/arch/ghc/src/ghc-6.8.3/libraries/base' > make[2]: *** No targets specified and no makefile found. Stop. > make[2]: Leaving directory `/home/twifkak/arch/ghc/src/ghc-6.8.3/libraries/base' > make[1]: *** [make.library.base] Error 2 > make[1]: Leaving directory `/home/twifkak/arch/ghc/src/ghc-6.8.3/libraries' > make: *** [stage1] Error 2 (This particular transcript is from an unclean build, but the same error occurred on a freshly untarred ghc.) The subsequent errors seems to stem from the root one of being unable to configure: > [twifkak@ponyride base]$ setup/Setup configure -v3 > Configuring base-3.0.2.0... > Creating dist (and its parents) > /home/twifkak/usr/bin/ghc --numeric-version > Warning: cannot determine version of /home/twifkak/usr/bin/ghc : > "" > Setup: ghc version >=6.2 is required but the version of /home/twifkak/usr/bin/ghc could not be determined. > [twifkak@ponyride base]$ ghc --numeric-version > 6.4 > [twifkak@ponyride base]$ setup/Setup configure --with-compiler=../../compiler/stage1/ghc-inplace -v3 > Configuring base-3.0.2.0... > Creating dist (and its parents) > ../../compiler/stage1/ghc-inplace --numeric-version > Warning: cannot determine version of ../../compiler/stage1/ghc-inplace : > "" > Setup: ghc version >=6.2 is required but the version of ../../compiler/stage1/ghc-inplace could not be determined. > [twifkak@ponyride base]$ ../../compiler/stage1/ghc-inplace --numeric-version > 6.8.3 What's going wrong? How do I fix it? Is there a better mailing list to ask? Thanks, Devin

2 3

Glut using freeglut and non starndard header / lib location?
by Marc Weber 19 Oct '08

19 Oct '08

Which is the way to install the glut library with non standard header / lib location? I've tried setting CFLAGS before running ./configure ./setup configure and adding the include directory this way include-dirs: include, /nix/store/rz4nfm5qcrjrk0jsr1lxnjwamgxmgip8-freeglut-2.4.0/include All results in checking for GL/glut.h... (cached) no checking GLUT/glut.h usability... no checking GLUT/glut.h presence... no checking for GLUT/glut.h... no configure: error: no GLUT header found, so this package cannot be built The configure script is meant to be run by cabal only? Marc

2 1