- Haskell-Cafe - Haskell.org

Finite Difference Implementation
by Fernan Bolando 27 Apr '08

27 Apr '08

Hi all I was wondering if anyone has or knows of a Finite Difference or Finite Element Implementation in pure haskell. I would like to write this myself, but my haskell skills is not that good. I did a bit of google search I've seen it bieng discussed, but did not point to an actual code. thanks fernan -- http://www.fernski.com

1 0

lookup tables & style guidelines
by Cetin Sert 27 Apr '08

27 Apr '08

Dear Haskell Devs ^_^, 1) what is the most performant lookup table/hashtable/dictionary solution for Haskell? 1.1) should I use size-balanced binary trees for that or is there a more common way? 2) are there any established style guidelines for haskell code? Best Regards, Cetin Sert

7 10

asserting the type of a binding in a "do" expression
by Ken Takusagawa 26 Apr '08

26 Apr '08

This works (with -fglasgow-exts): foo::IO Int; foo = do{ (x::Int) <- bar; return x;}; bar = undefined But this does not: foo::IO a; foo = do{ (x::a) <- bar; return x;}; Error message: A pattern type signature cannot bind scoped type variables `a' unless the pattern has a rigid type context. How can I accomplish my goal of asserting the type of x, as a programmer sanity check, when there are type variables? Thanks, --ken

4 3

Replacing RDMS - global lock and STM preventing retrying?
by Marc Weber 26 Apr '08

26 Apr '08

What would be the right way to go to replace RDBMS (postgres/ mysql) etc using haskell only for small to medium sized (web)applications? I guess one way to go is using STM. But what happens if you have some tables each row represented as TVar and you'd like to do a full backup? Some occasionally occuring updates on single rows will make the atomic action get all rows and write them to disk retry again and again? Is there a way to make the update action retry in this case? And then you can implement something like: Try it 20 times, if the aciton doesn't succeed aquire global lock ! Wow. Has anyone already implemented such a RDBMS replacement? Anyone interested in working on this? Marc Weber One solution I came up within minutes :) I love haskell. You write it down fix error and it works :) Would you prefer another way to solve this? --packages: containers, binary, stm, mtl, random module Main where import System.IO.Unsafe import Random import Control.Concurrent import Control.Monad import Control.Concurrent.STM import Control.Monad.Trans -- running count of actions. if set to -1 a transaction has aquired global lock globalLock = unsafePerformIO $ newTVarIO (0::Int) modifyTVar tvar f = do v <- readTVar tvar writeTVar tvar $ f v -- of course this should be in it's own monad to force using this function -- myAtomically: aquires global lock -- of course I don't need 5 atomically calls, but this way an action will not be retried if only the global count changes myAtomically aquireGlobalLock stmAction = if aquireGlobalLock then do atomically $ do runningCount <- readTVar globalLock when (runningCount /= 0) retry writeTVar globalLock (negate 1) -- other actions should be retrying atomically $ do stmAction writeTVar globalLock 0 else do atomically $ do runningCount <- readTVar globalLock when (runningCount == (negate 1)) retry modifyTVar globalLock (+1) atomically stmAction atomically $ modifyTVar globalLock (\x -> x -1) -- log utility printing start / stop of an action stsp :: (MonadIO m) => String -> m r -> m r stsp msg act = do liftIO $ putStrLn $ "start: " ++ msg r <- act liftIO $ putStrLn $ "stop: " ++ msg return r data Table rec = Table { table :: [TVar rec] } newTable rowcount = liftM Table $ mapM newTVarIO [(1::Int)..rowcount] dumpTable fn t = do dat <- myAtomically True $ mapM readTVar $ table t writeFile fn $ show dat disturb t@(Table (row:_)) = do stsp "disturbing" $ do v <- randomRIO (0,1000000) myAtomically False $ writeTVar row v threadDelay 1000000 disturb t -- loop main = do stsp "application" $ do table <- newTable 100000 forkIO $ disturb table stsp "dumping" $ dumpTable "dump" table

2 3

functional update
by Evan Laforge 26 Apr '08

26 Apr '08

Here's some haskell to update a particular field in a data structure (the below run in a StateT / ErrorT context): > set_track_width :: (UiStateMonad m) => > Block.ViewId -> Int -> Block.Width -> m () > set_track_width view_id tracknum width = do > view <- get_view view_id > track_views <- modify_at (Block.view_tracks view) tracknum $ \tview -> > tview { Block.track_view_width = width } > update_view view_id (view { Block.view_tracks = track_views }) Plus some utilities: > modify_at xs i f = case post of > [] -> throw $ "can't replace index " ++ show i > ++ " of list with length " ++ show (length xs) > (elt:rest) -> return (pre ++ f elt : rest) > where (pre, post) = splitAt i xs > update_view view_id view = modify $ \st -> st > { state_views = Map.adjust (const view) view_id (state_views st) } A similar imperative update would look something like this: > state.get_view(view_id).tracks[tracknum].width = width Has there been any work on improving update syntax in haskell? Possibly some improvement could be made with a typeclass or two and a few custom operators, to unify some of the disparate syntax. Maybe more improvement could be made with some TH hackery. A better record update syntax I'm sure could improve things even more. Or maybe there's a way to structure existing code to improve the above? Does anyone know of work that's been done on analysing functional update syntax issues, and coming up with something concise and clear? Other functional languages that do this better? It seems like an obvious candidate for improvement. Probably not an easy one though. There are various overlapping issues: monadic binds not mixing easily with non-monadic functions, different data structures (maps, lists, ...) having different update functions, record update syntax being super wordy, and probably some other things I'm not thinking of. As an aside, on the record system side, I would love to see one of the proposed record systems implemented in GHC, whether it be trex or the "lighter weight" version proposed by one of the Simons. Does anyone know what the main hangup is? Unresolved issues in the proposal? No consensus? Backward incompatibility? Not enough interested GHC devs? All I can say is that as a heavy user of (.) I wouldn't mind replacing them all with (#) or (@) or whatever if I got a nicer record syntax. It wouldn't be hard to write a search/replace for (.).

6 6

Why doesn't GHC use the Hugs definition of splitAt to avoid traversing the first part of the list twice?
by Richard Kelsall 26 Apr '08

26 Apr '08

I've just been investigating a performance oddity in using splitAt on a long stream of random numbers. I don't understand why GHC appears to want to traverse the first part of the list twice. GHC seems to implement the splitAt function something like splitAt n xs = (take n xs, drop n xs) whereas Hugs is something like splitAt n (x : xs) = (x : xs', xs'') where (xs', xs'') = splitAt (n-1) xs which seems much more sensible to me. Wouldn't it be better to change GHC to the Hugs method? Have I misunderstood something? Richard.

3 4

Function Type Calculation (revisited)
by PR Stanley 26 Apr '08

26 Apr '08

Hi I know we've already looked at the topic of function type calculation though last time I didn't have the chance to go through it thoroughly. So here it is again. Apologies for the repetition. I've had a try at calculating function types for two examples below. So to start with I'd be grateful for an assessment of my efforts. All comments are welcome. Thanks, Paul [1] funk f x = f (funk f) x f :: a x :: b funk f x :: c therefore funk :: a -> b -> c RHS f (funk f) x :: c f (funk f) :: d -> c x :: d f :: e -> d -> c funk :: h -> e f :: h unification f :: a = h = (e -> d -> c) x b = d therefore funk :: ((h -> e) -> b -> c) -> b -> c [2] w f = f f Assigning Types f :: a w f :: b therefore w :: a -> b RHS f f :: b f :: c -> b f :: c f :: a = b = c = (c -> b) therefore w :: (a -> a) -> a

1 0

n00b circular dep question
by Jennifer Miller 26 Apr '08

26 Apr '08

Hi all, This is my first post, and I'm a n00b, so go easy if I breach protocol. :-) I have a graph where the nodes contain a number of fields of various types. The values for one of those fields -- call it Mass -- need to reside in a separate file from the main graph definition (this is for workflow reasons and is given to me as a constraint). In order to set the Mass for a particular node, I need access to the other fields of that node. The other constraint is that the graph needs to be available in an interpreter (eg GHCi). So, I have a circular dependency in my modules that I don't know how to resolve in Haskell. I went looking for the equivalent of #include which is how I would have solved this in C++. I'm sure there is a simple answer to this and I'm hoping this group can point me in the right direction. Many thanks, ogina

6 7

a faster, accumulating mapM (was Re: [Haskell-cafe] mapM vs mapM_ performance)
by Ben 26 Apr '08

26 Apr '08

Hello Luke and other Haskellers, Thanks for the reply, but as I noted before, the amount of memory allocated (and resident) is roughly the same. Anyhow it's definitely not a GC issue because I wrote an accumulating version of mapM and got close to mapM_ 's performance. In the code below, main1 is mapM_, main2 is the current mapM (basicallly sequence . map), map3 is a hand-coded accumulating parameter version, mapM2 is the accumulating parameter mapM and main4 uses mapM2. The timings I get are about 15, 175, 20 and 20 seconds for main1, main2, main3 and main4 respectively. main2 uses about 2% less memory than main3 or main4 on this particular run, though I don't know if that is true generally. Unless someone can see a reason why mapM2 is not as good as mapM, can I suggest replacing the implementation of mapM by the implementation of mapM2. A 10x speedup seems to be a bigger deal than GCing 2% more memory. best regards, Ben module Main where import System.IO (openFile, IOMode(..), hPutStr) testlst = let ls = [(i, [(j, (fromIntegral j)::Float) | j <- [1..5]::[Int]]) | i <- [1..500000]::[Int]] in ls main = do h <- openFile "bardump" WriteMode mapM_ ((hPutStr h) . show) testlst main2 = do h <- openFile "bardump2" WriteMode result <- mapM ((hPutStr h) . show) testlst print $ length result main3 = do h <- openFile "bardump3" WriteMode result <- dump h testlst [] print $ length result where dump h (x:xs) accum = do hPutStr h $ show x dump h xs $ ():accum dump _ [] accum = return accum mapM2 :: Monad m => (a -> m b) -> [a] -> m [b] {-# INLINE mapM2 #-} mapM2 fn lst = mapM2accum fn lst [] where mapM2accum _ [] accum = return accum mapM2accum fn (x:xs) accum = do r <- fn x mapM2accum fn xs (r:accum) main4 = do h <- openFile "bardump2" WriteMode result <- mapM2 ((hPutStr h) . show) testlst print $ length result On Thu, Apr 24, 2008 at 1:37 AM, Luke Palmer <lrpalmer(a)gmail.com> wrote: > On Tue, Apr 22, 2008 at 11:32 AM, Ben <midfield(a)gmail.com> wrote: > > Hello Haskellers, > > > > I'm running ghc 6.8.2 on vista 64. Consider the following program, > > which is compiled with -02 -prof -auto-all: > > > > module Main where > > > > import System.IO (openFile, IOMode(..), hPutStr) > > > > testlst = let ls = [(i, [(j, (fromIntegral j)::Float) | j <- > > [1..5]::[Int]]) | i <- [1..500000]::[Int]] > > in ls > > > > main2 = do > > h <- openFile "bardump" WriteMode > > mapM_ ((hPutStr h) . show) testlst > > > > > > main = do > > h <- openFile "bardump2" WriteMode > > mapM ((hPutStr h) . show) testlst > > return () > > > > main and main2 are different in only that mapM_ versus mapM_ are used. > > But the mapM version runs about 20x slower! I'm running with +RTS -p > > -hc -RTS and I see that the amount of memory allocated is about the > > same, and I think the resident memory is about the same too. But the > > mapM_ version runs in about 8.7 seconds, and the mapM version takes > > 167 seconds. > > My first guess is that the garbage collector is not running at all in > the mapM_ version, but is working it's ass off in the mapM version > cleaning up the list that will never be used. > > > > You may ask, why use mapM if you're discarding the values? > > Unfortunately in my real app I need the values, which are more > > interesting than IO (). > > If you need the values, then you've got to pay that price I suppose. > If you need the values, I'm going to take a stab that in your real app > you use a lot of memory because of this (because presumably you're > keeping the values around), whereas you're just seeing a speed hit on > this small test program. > > Luke >

8 13

Trying to build a stand-alone executable GLUT app with ghc, Windows XP
by Peter Schmitz 26 Apr '08

26 Apr '08

Problem summary Trying to build a stand-alone executable GLUT app with ghc, Windows XP Problem description I compile and link (without errors) a simple GLUT application under Windows XP. When I run it, XP pops an error window saying the app cannot start due to a missing "glut32.dll". I want to do a static build to create a stand-alone executable GLUT app under Windows XP, without using DLL files, or placing any files in the Windows system dir. This is my first GUI code in Haskell, and I chose GLUT because it is a standard library. Following are some details. Thanks much for any advice. Source code -- Simple GLUT app to create a window module Main(main) where import Graphics.Rendering.OpenGL import Graphics.UI.GLUT main = do (progname, _) <- getArgsAndInitialize createWindow "Hello World" mainLoop Compile/run Environment ghc-6.8.2 on a USB flashdrive under a non-admin Windows XP account ghc dir is not on C: E:\apps\ghc\ghc-6.8.2 XP shell used: cmd.exe shell path E:\ghcTest>path PATH=C:\WINDOWS\system32;C:\WINDOWS;E:\apps\ghc\ghc-6.8.2\bin;.\ ghc library path E:\ghcTest>ghc --print-libdir E:/apps/ghc/ghc-6.8.2 compile/link output E:\ghcTest>ghc --make x -package GLUT [1 of 1] Compiling Main ( x.hs, x.o ) Linking x.exe ... E:\ghcTest> files (sizes in bytes) 186 x.hs 387 x.hi 3,184 x.o 498 x.exe.manifest 609,222 x.exe When application is run Error dialog window pops up window title a.exe - Unable To Locate Component window text The application has failed to start because glut32.dll was not found. Re-installing the application may fix this problem. No output in shell; no glut window is created. Other builds tried; same runtime error ghc --make x -package GLUT -static ghc -package GLUT x.hs -o x ghc --make x -package GLUT -LE:\apps\ghc\ghc-6.8.2\lib\GLUT-2.1.1.1 ghc --make x -LE:\apps\ghc\ghc-6.8.2\lib\GLUT-2.1.1.1 --

3 2