- Haskell-Cafe - Haskell.org

CAL experience
by Karel Gardas 15 Sep '10

15 Sep '10

Hello, as this is really friendly forum, I'd like to ask to perhaps solve my wonder. From time to time I'm seeing people here recommending Scala as a kind of replacement for non-existent Haskell on Java/JVM platform. My wonder is: why the people here do not recommend CAL, which at least to me, looks much more closer to Haskell than Scala is. Are there any bad experiences with this language and OpenQuark platform? I'm asking since I'm currently playing with it and plan to use it for java objects data processing. Thanks, Karel

3 2

copy of boost graph library
by Thomas Bereknyei 15 Sep '10

15 Sep '10

I was looking around and liked some of the ways that Boost organizes its libraries. So it got me thinking that it might be easy to use the same for a Haskell graph library. This IS NOT FGL, but does include some elements of it at the end (InductiveGraph). Mostly what I like, is that it presents a (somewhat) logical sequence of operations for a graph writer to implement, getting a few freebies along the way. There aren't too many extensions or complications. The most odd thing is the way I arranged the types. A quick look at some typesigs should clear up confusion, but: Node g is the entire node, eg (Int,a) NodeIndex is just the index eg Int NodeLabel is just the label eg. a the same for edge. I'm just fishing for ideas and opinions, and whether or not this seems simpler to use. http://codepad.org/UXUL7LZv {-# LANGUAGE TypeFamilies ,FlexibleContexts #-} --TODO: Visitors? DFF searches import qualified Data.IntMap as I import Data.List (find,unfoldr,foldl') import Data.Maybe (fromJust) import Control.Arrow (second) class Graph g where type NodeIndex g type EdgeIndex g type Node g --The entire node, including index, any labels and/or data. type Edge g --ditto node_index :: g -> Node g -> NodeIndex g edge_index :: g -> Edge g -> EdgeIndex g empty :: g isEmpty :: g -> Bool mkGraph :: [Node g] -> [Edge g] -> g class Graph g => DirectionalGraph g where edges_out :: g -> NodeIndex g -> [Edge g] source , target :: g -> EdgeIndex g -> Node g degree_out :: g -> NodeIndex g -> Int degree_out = length ... edges_out class DirectionalGraph g => BidirectionalGraph g where edges_in :: g -> NodeIndex g -> [Edge g] edges_both :: g -> NodeIndex g -> [Edge g] edges_both g n = edges_out g n ++ edges_in g n degree_in :: g -> NodeIndex g -> Int degree_in = length ... edges_in degree :: g -> NodeIndex g -> Int degree g n = degree_out g n + degree_in g n class Graph g => AdjacencyGraph g where nodes_out,nodes_in,nodes_both :: g -> NodeIndex g -> [NodeIndex g] class Graph g => VertexGraph g where nodes :: g -> [Node g] node :: g -> NodeIndex g -> Maybe (Node g) hasNode :: g -> NodeIndex g -> Bool hasNode g n = maybe False (const True) (node g n) order :: g -> Int order = length . nodes class Graph g => EdgeGraph g where edges :: g -> [Edge g] edge :: g -> EdgeIndex g -> Maybe (Edge g) hasEdge :: g -> EdgeIndex g -> Bool hasEdge g e = maybe False (const True) (edge g e) size :: g -> Int size = length . edges class Graph g => MutableGraph g where insert_node :: Node g -> g -> g --if preexists, update remove_node :: NodeIndex g -> g -> g insert_edge :: Edge g -> g -> g --if preexists, update remove_edge :: EdgeIndex g -> g -> g class Graph g => PropertyGraph g where type NodeLabel g type EdgeLabel g node_label :: Node g -> NodeLabel g edge_label :: Edge g -> EdgeLabel g node_labelize :: NodeIndex g -> NodeLabel g -> Node g edge_labelize :: EdgeIndex g -> EdgeLabel g -> Edge g get_node_label :: g -> NodeIndex g -> NodeLabel g get_edge_label :: g -> EdgeIndex g -> EdgeLabel g class (VertexGraph g,BidirectionalGraph g,MutableGraph g) => InductiveGraph g where data Context g edgesInC :: Context g -> [Edge g] nodeC :: Context g -> Node g edgesOutC :: Context g -> [Edge g] make_context :: [Edge g] -> Node g -> [Edge g] -> Context g --minimum definition is match or context, but default works too context :: g -> NodeIndex g -> Maybe (Context g) --context = fmap fst ... match context g n = do foundNode <- node g n return $ make_context (edges_in g n) foundNode (edges_out g n) match :: g -> NodeIndex g -> Maybe (Context g,g) match g n = fmap (flip (,) $ remove_node n g) $ context g n insert :: Context g -> g -> g insert c g = foldr insert_edge g'' (edgesOutC c) where g' = insert_node (nodeC c) g g'' = foldr insert_edge g' (edgesInC c) toContexts :: g -> [Context g] toContexts g = unfoldr matchIt (g, map (node_index g) $ nodes g) where matchIt (_, []) = Nothing matchIt (g', (n:ns)) = fmap (second (flip (,) ns)) $ match g n fromContexts :: [Context g] -> g fromContexts = foldr insert empty adjust :: (Context g -> Context g) -> NodeIndex g -> g -> g adjust f n g = maybe g (uncurry (insert . f)) $ match g n gfoldr :: (Context g -> b -> b) -> b -> g -> b gfoldr f i = foldr f i . toContexts gfoldl' :: (b -> Context g -> b) -> b -> g -> b gfoldl' f i = foldl' f i . toContexts gfilter :: (Context g -> Bool) -> g -> g gfilter f = fromContexts . filter f . toContexts class (InductiveGraph g) => MappableGraph g where gmap :: InductiveGraph g' => (Context g -> Context g') -> g -> g' gmap f = fromContexts . map f . toContexts nmap :: (InductiveGraph g,Edge g ~ Edge g) => (Node g -> Node g) -> g -> g nmap f = gmap f' where f' c = make_context (edgesInC c) (f $ nodeC c) (edgesOutC c) emap :: ( InductiveGraph g', Node g ~ Node g') => (Edge g -> Edge g') -> g -> g' emap f = gmap f' where f' c = make_context (map f $ edgesInC c) (nodeC c) (map f $ edgesOutC c)

2 1

Question on concurrency
by Arnaud Bailly 14 Sep '10

14 Sep '10

Hello Haskellers, Having been pretty much impressed by Don Stewart's "Practical Haskell" (http://donsbot.wordpress.com/2010/08/17/practical-haskell/) I started to write a Haskell script to run maven jobs (yes, I know...). In the course of undertaking this fantastic endeavour, I started to use the System.Process.readProcessWithExitCode function, but following the advice in the comment for this function, I rolled my own stuff and ended up writing the following: > doRunMvnInIO pom args filters e > = do (Just inh, Just outh, Just errh, pid) <- > createProcess (proc (maven e) (["-f", pom] ++ args)) { std_in = CreatePipe, > std_out = CreatePipe, > std_err = CreatePipe } > waitQ <- newEmptyMVar > > mapM (printAndWait waitQ) [outh, errh] > > hClose inh > -- wait on the process > waitForProcess pid > where > printAndWait waitQ hdl = do out <- hGetContents hdl > forkIO (mapM (putStrLn) (filter filters $ lines out) >> putMVar waitQ ()) > takeMVar waitQ > hClose hdl This is actually a rewrite of the following function: > doRunMvnInIO' pom args filters e > = do (Just inh, Just outh, Just errh, pid) <- > createProcess (proc (maven e) (["-f", pom] ++ args)) { std_in = CreatePipe, > std_out = CreatePipe, > std_err = CreatePipe } > waitQ <- newEmptyMVar > > mapM (printAndWait waitQ) [outh, errh] >>= mapM (\_ -> takeMVar waitQ) > > hClose inh > hClose outh > hClose errh > -- wait on the process > waitForProcess pid > where > printAndWait waitQ hdl = do out <- hGetContents hdl > forkIO (mapM (putStrLn) (filter filters $ lines out) >> putMVar waitQ ()) What surprised me is that I would expect the behaviour of the two functions to be different: - in doRunMvnInIO, I would expect stdout's content to be printed before stderr, ie. the 2 threads are ordered because I call takeMVar in between calls to forkIO - in doRunMvnInIO', this is not true and both theads run concurrently. but actually there does not seem to be a difference: printing is still interleaved in both functions, AFAICT. I would welcome any help on this. Best regards, Arnaud

2 2

Differences with Hayoo and Hoogle: Searching For Monoids
by aditya siram 13 Sep '10

13 Sep '10

Hi all, I was trying to read the documentation on monoids and the Sum type. When I searched Hayoo for "Monoid" or "Data.Monoid", the Data.Monoid module in "base" did not show up - Hoogle found it without a problem. The same goes for the "Sum" type, Hayoo does not seem to find it but Hoogle does. -deech

2 1

Haddock again
by Andrew Coppin 13 Sep '10

13 Sep '10

Some time ago (I can't find the thread now), I wrote about the fun and games I had with Haddock. After much experimentation, I have discovered that if you have a sufficiently new version of cabal-install, the configuration file has a field entitled "document-index:" or similar. If you uncomment this and use its default value, you get a documentation index generated for you. But ONLY if you do a user-install, not a global-install, for reasons beyond my comprehension. (I swear to God I got it to work with global installs one time...) Also, I commented that the links generated were broken, but it appears that if you have a sufficiently new version of Haddock, the links work just fine. (In other words, this particular bug is already fixed.) Finally, I notice that the master index links to the packages, but the packages do not link back. So it is impossible to navigate back to the master index other than using the browser's "back" button. This particular limitation seems to be present even in the shiny new release of Haddock. Really finally: It seems that all of Hackage has been redone using the new Haddock. Wow, that was quick...

1 2

Fwd: Type families - how to resolve ambiguities?
by Paolo Giarrusso 13 Sep '10

13 Sep '10

On Aug 25, 11:22 pm, Dan Doel <dan.d...@gmail.com> wrote: > On Wednesday 25 August 2010 5:05:11 pm DavidA wrote: > > The code below defines a type synonym family: > > > {-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-} > > {-# LANGUAGE FlexibleInstances, TypeSynonymInstances #-} [snip] > The problem with mult is that k is not specified unambiguously. You either > need v to determine k (which is probably not what you want, at a guess), mult > to take a dummy argument that determines what k is: [...] > or, to make Tensor a data family instead of a type family. What is the difference making it work? However, it would make more sense to have it be a type family, without the overhead of data (both in space and in typing). Is there a non- hacky approach, without dummies and without making Tensor a data family without a semantic need? I am having a similar problem with the vector package, with the Data.Vector.Generic.Mutable module, because of the PrimState type family. How am I expected to best solve this? This function is easy to write: fillVector n elems = do arr <- VectorGM.new n VectorG.copy arr $ VectorG.fromList elems return arr However, what I have below is not easy to write for me - some specific type annotations are needed. Interestingly, I needed to annotate a statement rather than the return value, because unifying PrimState IO and PrimState m fails, rather than producing m = IO. While I managed to make them work, it looks like type inference is not helping much - the code seems more complicated to properly type-annotate than it would be in a language with just typechecking. V1, not generic - it works for arrays of integers: fillSortVector n elems = do arr <- VectorGM.new n :: IO (VectorU.MVector (PrimState IO) Int) -- I can't annotate just arr, I need to annotate the IO action! -- arr :: (VectorU.MVector (PrimState IO) Int) <- VectorGM.new n -- doesn't compile! let arrI :: VectorU.Vector Int = VectorG.fromList elems VectorG.copy arr arrI (timing, _) <- timed $ VectorI.sort arr return timing V2, almost fully generic - but not in the array types (that was even more complicated IIRC): fillSortVector :: forall a. (Ord a, VectorG.Vector VectorU.Vector a, VectorGM.MVector VectorU.MVector a) => Int -> [a] -> IO Double fillSortVector n elems = do arr <- VectorGM.new n :: IO (VectorU.MVector (PrimState IO) a) -- I can't annotate just arr, I need to annotate the IO action! -- arr :: (VectorU.MVector (PrimState IO) a) <- VectorGM.new n -- doesn't compile! let arrI :: VectorU.Vector a = VectorG.fromList elems VectorG.copy arr arrI (timing, _) <- timed $ VectorI.sort arr return timing Best regards Paolo G. Giarrusso -- PhD student

3 2

Data.Text performance problem
by Petr Prokhorenkov 13 Sep '10

13 Sep '10

I experienced a following problem while dealing with some text processing. I have a text and want to get the same text with parts enclosed into {} or [] stripped away. Substituting them with a ' ' would also work. Here is the code I wrote (T is Data.Text): stripBrackets :: T.Text -> T.Text stripBrackets text = snd $ T.mapAccumL f 0 text where f depth c = let depth' = depth + d' c c' | depth > 0 || depth' > 0 = ' ' | otherwise = c in (depth', c') d' '{' = 1 d' '[' = 1 d' '}' = -1 d' ']' = -1 d' _ = 0 The only problem is that it takes about a minute to complete on 3GHz+ processor when text is a 30k chars long. Any ideas how to improve this code? -- Regards, Petr

4 5

Interruptable event loop
by Mitar 13 Sep '10

13 Sep '10

Hi! I have X11 code which looks something like the following. The problem is that TimerInterrupt gets sometimes thrown in a way that it kills the whole main thread. Probably it gets thrown in the middle of some nested function which unblocked exceptions. I found: http://hackage.haskell.org/trac/ghc/ticket/1036#comment:4 but this is not yet in GHC stable version. Is there some workaround for this? Because I have problems compiling current Haskell platform with GHC head. currentThread <- myThreadId _ <- forkIO $ timer currentThread block $ run display run display = do ... allocaXEvent $ \event -> do interrupted <- catch (unblock $ nextEvent' display event >> return False) (\(_ :: TimerInterrupt) -> return True) ... run display -- A version of nextEvent that does not block in foreign calls nextEvent' :: Display -> XEventPtr -> IO () nextEvent' d p = do pend <- pending d if pend /= 0 then nextEvent d p else do threadWaitRead (fromIntegral . connectionNumber $ d) nextEvent' d p data TimerInterrupt = TimerInterrupt deriving (Show, Typeable) instance Exception TimerInterrupt timer :: ThreadId -> IO () timer t = do threadDelay redrawInterval throwTo t TimerInterrupt timer t Mitar

1 1

ANN: ecu-0.0.0
by Tom Hawkins 13 Sep '10

13 Sep '10

This package is a collection of programs that we use at Eaton to interact with, debug, and analyze data from vehicle ECUs (Electronic Control Unit: automotive speak for an embedded computer). The motivation to put this stuff on hackage is to encourage the use of Haskell in automotive electronics and to help standardize open data formats and protocols -- the most common formats and protocols in this industry are proprietary. (The other motivation for hackage is it makes it easy for us to distribute tool updates to our engineers and technicians in the field. :-) ) Most of these programs in this package read or write data on a CAN bus. At work we use Kvaser CAN cables, so these tools link in Kvaser's open source CAN driver library, canlib. However, we anticipate adding several tools that have nothing to do with CAN -- they could be general data analysis programs that could be applicable to other fields, not just automotive. My question is, is it possible for a user to select which programs to install within a given package? I could see where someone would want to install a data analysis tool, but not want to bother with separately installing Kvaser canlib. I had considered different packages for the individual tools, but that would get messy pretty quick, especially since many tools share a lot of common code. Another question: Can we get a Hackage category specifically for the use of Haskell in embedded systems? I didn't see anything that stood out. And one last question: The Kvaser canlib library has a different name depending on if the machine is Linux or Windows. What is the best way to configure the build based on the platform? Current I have the library name hard coded in the extra-libraries field in the cabal file. -Tom http://hackage.haskell.org/package/ecu http://github.com/tomahawkins/ecu

5 6

Disable LINE Pragma handling in GHC
by JP Moresmau 13 Sep '10

13 Sep '10

Hello fellow Haskellers, In EclipseFP we use the GHC API for IDE related stuff like syntax highlighting and code outlines. However, I ran into something funny yesterday: when a source file contains LINE pragmas ( http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/pragmas.html#line-p…) all the locations for tokens are changed to reflect the pragmas information. While this is great in the "normal' GHC usage, this is not so great for us, because we're interested in that source code, not in original code. I haven't seen any flag to turn that behavior off in the docs, nor in the Lexer code, but have I missed something? Can I tell GHC to just ignore these pragmas? I suppose even using GHC for building and something else (haskell-src-exts?) for code handling would leave us with compilation messages at the wrong place. Thanks, -- JP Moresmau http://jpmoresmau.blogspot.com/

5 7