November 2008 - Haskell-Cafe

Physics engines purely in Haskell?
by Mark Wassell 09 Nov '08

09 Nov '08

Has anyone thought about or embarked on the task of developing a 2D or 3D physics engine purely in Haskell? There is Hipmunk but I'm wondering about a purely Haskell implementation; possibly a port of Chipmunk to Haskell. Mark

3 2

Is there a plan for HappS and ghc-6.10.1?
by Hugo Pacheco 09 Nov '08

09 Nov '08

Hi all, The HappS version on Hackage does not yet support ghc 6.10, since GADT pattern matching and the Exception API have changed. One sample error is: src/HAppS/Data/Xml/Base.hs:281:23: GADT pattern match with non-rigid result type `t1' Solution: add a type signature ... Adding a type signature via an auxiliary function instead of a case expression, the problem goes away. readElementRigidity :: (Monad m,Xml t) => Rigidity m -> m ([Element],t) -> Maybe t readElementRigidity Rigid m = ... readElementRigidity Flexible m = ... Is there a plan to update the version on Hackage to support ghc 6.10.1? I don't know either if it may break backwards compatibility. Cheers, hugo -- www.di.uminho.pt/~hpacheco

2 2

Convolution
by Andrew Coppin 09 Nov '08

09 Nov '08

A simple and straight-forward way to define the DSP operations of correlation and convolution is as follows: correlate1 :: [Double] -> [Double] -> Double correlate1 ks = sum . zipWith (*) ks correlate :: [Double] -> [Double] -> [Double] correlate ks [] = [] correlate ks xs = correlate1 ks xs : correlate ks (tail xs) convolute :: [Double] -> [Double] -> [Double] convolute ks = correlate (reverse ks) This very simple code work - and actually works quite well. It has the nice property of generating output from input lazily, as it is demanded. If the correlate function could be altered to use Prelude list functions only, I would think the above code works quite well with stream fusion too. (Presumably you could do this using "inits" or something?) Assuming DPH ever becomes a reality, how would you implement the above with it? (My intuition tells me that unless you have a really *big* filter kernel, breaking correlate1 into parallel chunks is too granular. However, each call to correlate1 could be run independently, presumably confering a more or less linear speedup. Unless having two cores writing to the same memory page is going to upset the cache system...) Presumably if you want to use parallel arrays, then the data must all exist in memory at once, and any chunking must be implemented manually and tediously?

2 3

Dealing with CStringLen
by Maurício 08 Nov '08

08 Nov '08

Hi, How is CStringLen supposed to be used? The only usual C string I'm familiar with is the null terminated sequence of chars. I remember some Pascal version where the first 2 bytes were used as an integer counting the following characters. What is the convention used in Foreign.C.String? I have a C function signature like this: void function (int,const void*,int,const void*) where each (int,const void*) pair is a string. Can (should) I use CStringLen here? How? Thanks, Maurício

2 1

view patterns
by Cetin Sert 08 Nov '08

08 Nov '08

let has [] = False; has _ = True -- this one is ok let empty list = case has list of True -> False; False -> True -- the following is problematic let emp (has -> True) = False; emp (has -> False) = True <interactive>:1:4: Warning: Pattern match(es) are overlapped In the definition of `emp': emp ((has -> True)) = ... emp ((has -> False)) = ... Why do I get this error in ghc or when I try to compile a file with view patterns? (using -fglasgow-exts and -XViewPatterns, ghc 6.10.1)

4 3

Haskell Quick Reference (1-page PDF)
by Malcolm Wallace 08 Nov '08

08 Nov '08

Some time ago, there was a thread about a "CheatSheet" for Haskell beginners. As I recall, the CheatSheet was more than 12 pages long. For a Haskell tutorial I was running at a conference recently, I needed a "Quick Reference Guide" that would fit onto a single side of A4. So I knocked one together quickly, and it is attached as a PDF. I send it to this list, with permission for anyone to distribute it more widely as they wish, in the hope that it might be useful. Doubtless it is incomplete, and I have no particular desire to fix errors or maintain this document, so if anyone is interested and would like to adopt it, I can pass on the editable sources. It was originally created as an Apple Numbers spreadsheet (simply for speed of creation) but could be converted to Excel or CSV, for import into other tools. Regards, Malcolm

4 3

Bit Field Marshalling
by Michael D. Adams 07 Nov '08

07 Nov '08

I'm writing a Storable instance for a data type that marshals to a C structure that contains bit fields such as the following: struct Foo { short x; short y; unsigned int a : 1; unsigned int b : 1; unsigned int c : 1; unsigned int d : 1; unsigned int reserved : 12; } For the "x" and "y" fields I've been using hsc2hs and something like #{peek Foo, x} to extract the fields. However, bit fields such as "a" have me stumped. But as far as I can tell, hsc2hs doesn't support bit fields. On top of that I'm not sure I can make any safe assumptions about what order the bit fields are packed (LSB or MSB first). Have others run into this problem before? What options are there for working around it? Michael D. Adams mdmkolbe(a)gmail.com

5 5

performance difference for binary-0.4.3.1 with ghc-6.8.3 and ghc-6.10
by John Lato 07 Nov '08

07 Nov '08

Hello, I was experimenting with using ghc-6.10.0.20081007 on a project, and it seems that binary-0.4.3.1 has markedly worse performance in certain cases. With the following simple test: > import qualified Data.ByteString.Lazy as L > import Data.Binary > import Data.Binary.Get > import Control.Monad > > main :: IO () > main = do > b <- L.readFile "some_binary_file" > putStrLn $ show $ runGet getter b > getter :: Get [Word16] > getter = replicateM 1000000 getWord16le running this program compiled with ghc-6.10 takes about 4 times as long (and consumes much more memory) as when compiled with ghc-6.8.3. The extra time appears to be proportional to the number of elements processed in the Get. Running the programs with -hT shows a clear memory difference, which I think is the source of the problem. I've placed pdfs of that output at https://webspace.utexas.edu/latojw/data/ The difference seems to manifest itself only when the elements are actually processed; changing "show $ runGet " to "show $ length $ runGet " is slightly faster in 6.10. I was working on an Intel Mac with OS 10.4, binary-0.4.3.1, and bytestring-0.9.1.4. Can anyone confirm this, or suggest what might be the difference? Thank you, John Lato

6 9

Monad.Reader with updates
by Mauricio 07 Nov '08

07 Nov '08

Hi, Is there some abstraction in current ghc library that implements something like Reader, but where the value of the environment is updated at every "step"? I imagine something that instead of running like this: runReader ( do ... ) environment I would run like: runReader ( do ... ) environment update_function So, when I write a monad like: do a <- asks f b <- asks f2 c <- asks f3 f, f2 and f3 would be called with parameters environment, (update_function environment), (update_function . updatefunction $ environment) etc. Does that make sense? Is it easy to adapt something already existing to do that? Thanks, Maurício

7 12

Problems with strictness analysis?
by Patai Gergely 07 Nov '08

07 Nov '08

Hi everyone, I was experimenting with simple accumulator functions, and found that an apparently tail recursive function can easily fill the stack. Playing around with ghc and jhc gave consistently unpleasant results. Look at this program: %%%%%%%%%%% -- ghc: no, ghc -O3: yes, jhc: no isum 0 s = s isum n s = isum (n-1) (s+n) -- ghc: no, ghc -O3: no, jhc: yes (because gcc -O3 is clever) rsum 0 = 0 rsum n = n + rsum (n-1) main = case isum 10000000 0 {- rsum 10000000 -} of 0 -> print 0 x -> print x %%%%%%%%%%% I would expect the analysis to find out that the result of the function is needed in every case (since we are matching a pattern to it), yet I need to add a $! to the recursive call of isum to get a truly iterative function. It's interesting how ghc and jhc seem to diverge, one favouring the "iterative" version, the other the "recursive" one (although it only works because gcc figures out that the function can be expressed in an iterative way). Of course this is a real problem when I'm trying to write an actual program, since it means I can be bitten by the laziness bug any time... Is there any solution besides adding strictness annotations? Can I expect the compiler to handle this situation better in the foreseeable future? Gergely -- http://www.fastmail.fm - IMAP accessible web-mail

17 35