- Haskell-Cafe - Haskell.org

message passing style in Monad
by jinjing 14 Sep '08

14 Sep '08

I found that as I can do xs.map(+1).sort by redefine . to be a . f = f a infixl 9 . I can also do readFile "readme.markdown" <.> lines <.> length by making a <.> b = a .liftM b infixl 9 <.> Kinda annoying, but the option is there. - jinjing

3 3

Views
by Stephan Friedrichs 14 Sep '08

14 Sep '08

Hello! List-like data structures should IMHO provide safe versions of 'head' and 'tail' (with safe I mean 'not partial', i. e. functions that don't provoke an 'error' when called with an empty collection). As far as I know, this is usually called 'view' and and has a type signature like view :: SomeDataStructure a -> View a with data View = Empty | Cons a (SomeDataStructure a) A good example for this is Data.Sequence. My question is: Why is this not expressed in terms of Maybe? view :: SomeDataStructure a -> Maybe (a, SomeDataStructure a) This would be easier to use, as there's no need for a new View type and because Maybe already provides instance declarations for a lot of useful classes (Functor, Monad, etc.) and handy helper functions (e. g. 'maybe'). Then you could, for instance, say: head xs = maybe undefined fst (view xs) tail xs = maybe undefined snd (view xs) You can of course argue that you want viewl and viewr to have different types in the case of Data.Sequence, but this is not the case for other, rather one-ended, data types, is it? Long story short, my problem is the following: I want to provide a 'view' function for Data.Heap in my heap [1] package and I don't know whether... a) ... to use Maybe b) ... to provide my own Data.Heap.View type c) ... a Data.View package with a View type should be included in the containers- or even base-package. This would prevent lots of small projects from creating totally equivalent View types. Maybe there even exists a Data.View package that I didn't find? Regards, Stephan [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/heap-0.3.1 -- Früher hieß es ja: Ich denke, also bin ich. Heute weiß man: Es geht auch so. - Dieter Nuhr

5 7

random colors, stack space overflow, mersenne and mersenne.pure64
by Cetin Sert 14 Sep '08

14 Sep '08

Hi, The following piece of code runs just fine, if I say: instance Random RGB where random = color randomR = colorR instead of: instance Random RGB where random = color2 randomR = colorR When I use random = color2 I encounter a stack space overflow: cetin@linux-d312:~/lab/test/colors> ./var2 +RTS -K30000000 Stack space overflow: current size 30000000 bytes. Use `+RTS -Ksize' to increase it. I think I'm doing something wrong with the definition of colorR. Can anyone explain me what's wrong? import GHC.Word import Data.Word import System.Random import System.Random.Mersenne.Pure64 type RGB = (Int,Int,Int) instance Bounded RGB where minBound = minRGB maxBound = maxRGB minRGB = (0 ,0 ,0 ) maxRGB = (255,255,255) instance Random RGB where random = color2 randomR = colorR color2 :: RandomGen g ⇒ g → (RGB,g) color2 = colorR (minRGB,maxRGB) color :: RandomGen g ⇒ g → (RGB,g) color s0 = ((r,g,b),s3) where (r,s1) = q s0 (g,s2) = q s1 (b,s3) = q s2 q = randomR (0,255) colorR :: RandomGen g ⇒ (RGB,RGB) → g → (RGB,g) colorR ((a,b,c),(x,y,z)) s0 = ((r,g,b),s3) where (r,s1) = q (a,x) s0 (g,s2) = q (b,y) s1 (b,s3) = q (c,z) s2 q = randomR main :: IO () main = do mt ← newPureMT let cs = randoms mt :: [RGB] print cs ------------------------------------------ This one also just works fine: import Data.Word import System.Random.Mersenne type RGB = (Word8,Word8,Word8) instance MTRandom RGB where random m = do r ← random m :: IO Word8 g ← random m :: IO Word8 b ← random m :: IO Word8 return (r,g,b) main :: IO () main = do g ← newMTGen Nothing cs ← randoms g :: IO [RGB] print cs but I really need the range constraints colorR might provide me and would greatly appreciate any help to understand/solve the issue. Best Regards, Cetin P/s: uname -a Linux linux-d312 2.6.25.16-0.1-default #1 SMP 2008-08-21 00:34:25 +0200 x86_64 x86_64 x86_64 GNU/Linux

6 13

Heads Up: code.haskell.org is upgrading to darcs 2
by Duncan Coutts 14 Sep '08

14 Sep '08

This email is for darcs users in general and in particular for people who host a project on code.haskell.org. What we are doing ================= We are upgrading /usr/bin/darcs to version 2 on the machine that hosts code.haskell.org. That means it will be used by everyone who uses ssh to push or pull from a darcs repository on code.haskell.org. Pulling via http is completely unaffected. Do I have to do anything? ========================= No. You do not have to change anything. darcs v2 can talk to darcs v1 clients perfectly well so you do not need to upgrade your local version of darcs. You do not need to change the format of your local or server-side repositories. Darcs v2 works fine with darcs v1 format repositories. Should I change anything? ========================= We recommend that you upgrade your local darcs to version 2. This will allow you to take advantage of substantially faster push/pull operations over ssh (darcs 2 makes far fewer ssh connections). As noted above however it is not necessary for you to upgrade or for you to synchronise your upgrading with anyone else who uses the same repository. It is also possible to use a darcs "v1.5" hashed format locally and continue to use darcs v1 format on the server side. This has some performance and reliability advantages. Again this is something you can decide yourself without coordinating with other users of the repository. If your development style means that you bump into the infamous merging problems with darcs v1 format then you may consider converting your repository to the darcs v2 format. Remember that using darcs 2 with darcs v1 format repositories does not eliminate the merging issue. To banish the merging problems you have to use the darcs v2 format. This is however a more substantial change and has to be synchronised between users of the repository because it involves converting the server side repository to v2 format and all users getting the repository again. So if merging is an issue for you then you should discuss it with other users of your repository. Is this change safe? ==================== Yes. Darcs 2 has a substantial test suite. It has unit tests covering the core patch operations and also over 100 scripts doing functional testing, including network tests. The darcs build-bots run all these tests on all the popular platforms. Additionally, the code in darcs 2 for handling the v1 format is mostly the same as in darcs 1, so there are no big risks in using darcs 2 while continuing to use darcs v1 format repositories. The main change in the v1 format code is bug fixes, instrumentation code for debugging/introspection and more cunning types in the patch handling code that enforces some of the patch invariants. Furthermore, we have done real world tests using copies of all the 153 repositories on code.haskell.org which comes to around 2GB. We wanted to verify a couple things: 1. that using darcs 1 on the client and darcs 2 on the server works fine to pull and push patches. This corresponds to a project where all the users are still using darcs 1. 2. that using a mixture of darcs 1 and darcs 2 clients works when pushing and pulling patches between the clients via the server. This corresponds to a project where some users have upgraded but others have not yet. We tested with darcs 1.0.9 and 2.0.2 in three combinations: client darcs 1, server darcs 1 client darcs 1, server darcs 2 client darcs 2, server darcs 2 The test consisted of obliterating a significant number of patches from each repository and pushing them back. In a separate experiment each repository was converted to darcs v2 format which worked without problem in every case. What if I have problems? ======================== Contact support(a)community.haskell.org. We have made backups of all the repositories in case there are any critical problems. Thanks to the darcs hackers Eric Kow and Jason Dagit for doing all the hard testing work. Duncan, Ian and Malcolm (part of the community server admin team)

4 5

static linking failure -- can't find crt0
by Jason Dusek 14 Sep '08

14 Sep '08

I'm building a "really static" executable on OS X with options `-optl-static -static` and, while the libraries seem to link fine, the executable itself does not -- it can't find the C runtime. This is actually by design -- Apple "does not support" static binaries. There is a work around -- just symlink stuff till the errors go away -- but it might be better if I could statically link only those C libraries that I knew were not on stock Macs. Are there GHC options for that? I assume this all works fine on Linux and Windows, but I'll know soon enough... -- _jsn |...can't find the C runtime.| ld_classic: can't locate file for: -lcrt0.o collect2: ld returned 1 exit status |"does not support"| http://developer.apple.com/qa/qa2001/qa1118.html

1 0

nooby question on typing
by Han Joosten 13 Sep '08

13 Sep '08

Hi, I have a question about types in Haskell. I feel that I am overlooking some obvious solution, but I do not manage to get it right. Here is the plot: I have got 4 different types of 'rules', each with it's own constructor. So i defined: > type Rules = [Rule] > data Rule = RuRule > | SgRule > | GcRule > | FrRule > deriving (Eq,Show) > data RuRule > = Ru { rrsrt :: Char > , rrant :: Expression > , rrfps :: FilePos > } deriving (Eq,Show) > data SgRule > = Sg { srfps :: FilePos > , srsig :: Rule > , srxpl :: String > , srtyp :: (Concept,Concept) > } deriving (Eq,Show) > data GcRule > = Gc { grfps :: FilePos > , grspe :: Morphism > , grgen :: Expression > } deriving (Eq,Show) > data FrRule > = Fr { fraut :: AutType > , frdec :: Declaration > , frcmp :: Expression > , frpat :: String > } deriving (Eq,Show) Now I would like to be able to use these rules without knowing what kind they are, in lists, however i get errors like Couldn't match expected type `Rule' against inferred type `SgRule'. Is there any other (even trivial?) way to get this done? I know Haskell well enough to know that it is possible, but I don not know Haskell well enough to know how to do it :teeth: Any help is kindly appreciated! Han Joosten -- View this message in context: http://www.nabble.com/nooby-question-on-typing-tp19470727p19470727.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

4 3

Fwd: Computer Language Benchmarks Game: [Which parallel problem would you add and why?]
by Don Stewart 13 Sep '08

13 Sep '08

The Computer Language Benchmarks Game has a quad core (as you probably know). But they're looking for new benchmarks. Ones that can actually exploit parallelism. If you've got suggestions on good parallelism benchmarks, and why they're good, add them to the alioth or reddit threads. ----- Forwarded message from Isaac Gouy ----- "Which parallel problem would you add and why?" http://alioth.debian.org/forum/forum.php?thread_id=14502&forum_id=2840 "Ask Proggit: Which parallel problem would you add now The Computer Language Benchmarks Game is measured on quad-core hardware, and why?" http://www.reddit.com/r/programming/comments/718qf/ask_proggit_which_parall… ----- End forwarded message -----

1 0

Hackage needs a theme song!
by Jason Dagit 13 Sep '08

13 Sep '08

I realized tonight that Hackage needs a theme song. Here is my attempt at it, apologies to Jefferson Starship: We built this hackage, We built this hackage on lambda and types Say you don't know me, or the parameters I pass Say you don't care who instances this type class Knee deep in the thunk, value infinitely big Too many constraints eating up the type sig Main runs the Monad, Listen to the Reader Don't you remember? We built this hackage We built this hackage on lambda and types! We built this hackage, we built this hackage on lambda and types Built this hackage, we built this hackage on lambda and types Someone always playing package games Who cares they're always changing package names We just want to compile here, someone stole the type hack They call us lazy, evaluate us off the stack Main runs the Monad, Listen to the Reader Don't you remember? We built this hackage We built this hackage on lambda and types! We built this hackage, we built this hackage on lambda and types Built this hackage, we built this hackage on lambda and types It's just another version in our release style Cabal has got the build deps, and we upload the file Who counts the downloads underneath package node Who writes the type errors into our source code Don't tell us you need us, 'cause we're the db of tools Looking for pragmas, crawling through your RULES Don't you remember ... Main runs the Monad, Listen to the Reader - Don't you remember? We built this hackage, We built this hackage on lambda and types We built this hackage, we built this hackage on lambda and types Built this hackage, we built this hackage on lambda and types Built this hackage, we built this hackage on lambda and types Built this hackage, we built this hackage on lambda and types We built, we built this hackage yeah We built this hackage We built, we built this hackage (Repeat - fade)

2 1

Windows details
by Andrew Coppin 13 Sep '08

13 Sep '08

I rather doubt anybody will know the answer to this, but I'll ask anyway... Under MS Windows, if you right-click on an executable file and select "properties", sometimes there's a "Version" tab that tells you the version number of the program. And sometimes there isn't. (Most especially, GHC-compiled programs do not have this tab.) Anybody know how to go about adding this? Also, anybody know how to give a GHC-compiled program a custom icon? If it's going to be really difficult then I won't bother, but it'd be interesting to know. (In other news, today I discovered that applying UPX to my 2.8 MB GHC-compiled executable shrinks it down to 800 KB and it still functions. And WinZip shrinks it down to just 300 KB. 2.8 MB for a program that just does a little text parsing does seem a touch excessive to me...)

5 16

Erroneous package listings in hackage?
by Dougal Stanton 13 Sep '08

13 Sep '08

$ cabal update ... $ cabal list | less ... * cairo Latest version installed: 0.9.13 Homepage: http://haskell.org/gtk2hs/ License: BSD3 ... $ cabal install cairo cabal: There is no package named cairo I must admit I was surprised to see a gtk2hs module on Hackage, but not half as surprised when I found it wasn't there after all... D

3 4