- Haskell-Cafe - Haskell.org

Re: Why is there no splitBy in the list module?
by Yitzchak Gale 11 Jul '06

11 Jul '06

I personally use split :: Eq a => [a] -> [a] -> [[a]] all the time, much more often than splitBy :: (a -> Bool) -> [a] -> [[a]] But I don't call it "split". By analogy with concatMap, the Haskell analogue of Perl/Python "join" is concatIntersperse. Then, by analogy with lines/unlines, the Haskell analogue of "split" is... unconcatIntersperse. Hmm...

2 1

Defining show for a function type.
by Johan Grönqvist 11 Jul '06

11 Jul '06

I am a haskell-beginner and I wish to write a Forth-like interpreter. (Only for practice, no usefulness.) I would like use a list (as stack) that can contain several kinds of values. data Element = Int Int | Float Float | Func : Machine -> Machine | ... Now I would like to have this type be an instance of the class Show, so that I can see what the stack contains in ghci. "deriving Show" is impossible as Func is not instance of Show. Can I make it instance of Show? I just want to define something like show (Func _) = "Function, cannot show" and I am not interested in actually displaying any information about the function, but I am interested in getting information about elements of other kinds. So far I have just guessed, but failed to produce anything that does not give an error stating that my function is not of the form (T a b c) where T is not an alias and a b c are simple type variables (or so). Any help appreciated! Johan

7 7

Re: [Haskell-cafe] Re: Why is there no splitBy in the list module?
by Donn Cave 11 Jul '06

11 Jul '06

Quoth John Meacham <john(a)repetae.net>: ... | just a note: I find splitBy a much nicer routine to provide. | |> splitBy :: (a -> Bool) -- ^ whether char is a separator |> -> [a] -- ^ list to split |> -> [[a]] Starting from the assumption that in most cases the list to be split will be [Char], so we can reasonably hold this up against string functions in other languages -- I think split is commonly split :: String -> String -> [String] i.e., the separator is [a], not a. Of course next they'll want regular expressions, but I use string separators of length > 1 a lot and rarely bother with regexps. But string splitBy might be an interesting alternative to regexp splits. Something like splitBy :: ([a] -> Maybe Int) -> [a] -> [[a]] breakBy :: ([a] -> Maybe Int) -> [a] -> Maybe ([a], [a]) breakBy f s = by [] f s where by _ _ [] = Nothing by c f s@(a:ax) = case f s of Just n -> Just ((reverse c), (drop n s)) Nothing -> by (a:c) f ax splitBy f s = case breakBy f s of Just (l, r) -> l:(splitBy f r) Nothing -> [s] Where in the simplest case the matching function would simply compare with a separator string, but could easily do more - eat up trailing blanks, for example. Note use of Maybe, basically to disambiguate end of data with and without match. Donn Cave, donn(a)drizzle.com

1 0

Re: [Haskell-cafe] type dependency
by Donn Cave 11 Jul '06

11 Jul '06

Quoth Henning Thielemann <lemming(a)henning-thielemann.de>: ... | Will you make that plotter wrapper public? Why not - I don't expect it's going to be big news in the computing world, but it's easy to set the files up. See http://staff.washington.edu/donn/ezp/hsezp.html Thanks to Bulat for the tip on multi-parameter typeclass. Donn Cave, donn(a)drizzle.com

1 0

Help building HSQL...
by Martin Percossi 10 Jul '06

10 Jul '06

Hi, I'm trying to build HSQL, in order to use HaskellDb. The base directory (i.e. HSQL) builds ok, as per instructions, but the PostgreSQL directory fails with the error message: Setup.lhs:17:71: Couldn't match `PackageDescription' against `LocalBuildInfo' Expected type: Args -> ConfigFlags -> LocalBuildInfo -> IO ExitCode Inferred type: [String] -> ConfigFlags -> PackageDescription -> LocalBuildInfo -> IO ExitCode In the `postConf' field of a record In the record update: defaultUserHooks {preConf = preConf, postConf = postConf} My version of ghc is 6.4.2. My installed packages are (using "ghc-pkg list"): Cabal-1.0, (Cabal-1.1.4), GLUT-2.0, HUnit-1.1, MissingH-0.14.2, OpenGL-2.0, QuickCheck-1.0, base-1.0, (concurrent-1.0), (data-1.0), fgl-5.2, haskell-src-1.0, haskell98-1.0, hsql-1.7, (hssource-1.0), (lang-1.0), mtl-1.0, (net-1.0), network-1.0, parsec-1.0, (posix-1.0), readline-1.0, rts-1.0, stm-1.0, template-haskell-1.0, (text-1.0), unix-1.0, (util-1.0) Note that I have installed all of these packages, and ghc into my ~/opt directory, as I don't have root. Has anyone seen the above error message before? Am I using the incorrect version of Cabal? Any help appreciated. TIA Martin

2 1

lists as instances of a class?
by David Roundy 10 Jul '06

10 Jul '06

(This email is a literate haskell program that fails to compile without -fglasgow-exts.) I'm sure I'm missing something lame here, but can someone tell me why we apparently can't declare a list to be an instance of a class in Haskell 98? Or is there perhaps some other syntax by which I'd declare this instance? If so, is this slated for fixing in Haskell'? $ ghc Test.lhs Test.lhs:6:1: Illegal instance declaration for `Vec [Double]' (The instance type must be of form (T a b c) where T is not a synonym, and a,b,c are distinct type variables) In the instance declaration for `Vec [Double]' > module Vec where > class Vec v where > (.+.) :: v -> v -> v > instance Vec [Double] where > xs .+. ys = zipWith (+) xs ys > instance Vec Double where > x .+. y = x + y feeling very stupid, David P.S. This is with ghc 6.4.1. And oddly enough, if you make the instance instance Num a => Vec [a] where xs .+. ys = zipWith (+) xs ys it works fine, but this strikes me as quite an ugly hack. I really want only Doubles to be instances of this class (which I've abbreviated for this email).

7 6

question about haskell wiki copy-rights
by Bulat Ziganshin 10 Jul '06

10 Jul '06

Hello haskell-cafe, i plan to write sometimes a Haskell performance tutorial. am i correctly understand that i can include contents of existing haskell wiki pages as long as tutorial will be published only on haskell wiki? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

3 2

Packages and modules
by Brian Hulley 10 Jul '06

10 Jul '06

Hi - At the moment there is a problem in that two packages P and Q could contain the same hierarchical module eg Data.Foo, and the only way for user code to ensure the "right" Data.Foo is used is to ensure that packages P and Q are searched in the right order. However suppose P and Q also contain another module with the same name, eg Data.Bar. And suppose a user module wants to use Data.Foo from P but Data.Bar from Q!!! I'm wondering: would it not be easier to just make it that the package name is prepended to the hierarchical module name, so the modules would instead be called by the names P.Data.Foo and Q.Data.Bar? As I see it, this would have at least these advantages: 1) A package author would only have to ensure that the name of the package (eg Edison, FPS, Base) is globally unique, and would then be free to name the modules in the package without having to worry about conflicts with other packages 2) Users of packages could specify exactly which modules they want to use, which would also make it easier to switch between different implementations of the same data type provided by different people etc 3) When you read the program text, you could immediately see which packages the modules came from, so you would know which packages you need to download if you don't currently have that module on your system. (At the moment, if I come across "import Data.Foldable" I've got no idea where to get it from.) It seems to me that the only reason this wasn't done in the first place was that originally there was just a flat module namespace, whereas with hierarchical modules it seems obvious to put the package name at the beginning (eg in Java the modules are called java.xyz, com.company.xyz etc to ensure there are no namespace conflicts) (On the Haskell' wiki there is http://hackage.haskell.org/trac/haskell-prime/wiki/SolveThePackageAbstracti… but this doesn't appear to consider the above solution.) Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com

16 37

Trace parser
by Andy Georges 10 Jul '06

10 Jul '06

Hello, I'm looking for a bit of help (ok, a lot) the speed up my program which I use to build a calltree out of an annotated program execution trace. To give you an idea about the sluggishness at the moment, for a trace containing 70MB, it has been running for about 10 hours straight (AMD Athlon XP (Barton) 2600+). The trace contains lines made up of a number of fields: C 4 1000 1000000 C 4 1001 1000200 R 4 1001 1003045 R 4 1000 1003060 C indicates a function entrypoint (call), R indicates a function exitpoint (return). The second field indicates which thread is executing the function, the third field denotes the function id, the last field contains a performance counter value. As you can see, numbering each line with a pre-order and a post-order number yields a list that can be transformed easily into a tree, which can then be manipulated. The first goal is to build the tree. This is done in the following code: data ParserState = ParserState { methodStack :: !ThreadMap , methodQueue :: !ThreadMap , pre :: !Integer , post :: !Integer , methodMap :: !MethodMap , currentThread :: !Integer } deriving (Show) initialParserState :: ParserState initialParserState = ParserState e e 0 0 e 0 where e = M.empty :: Map Integer a readInteger :: B.ByteString -> Integer readInteger = fromIntegral . fst . fromJust . B.readInt parseTraceMonadic :: [B.ByteString] -> ParserState parseTraceMonadic ss = state { methodQueue = M.map reverse (methodQueue state) } where state = execState (mapM_ (\x -> modify (updateState x) >> get >>= (`seq` return ())) ss) initialParserState updateState :: B.ByteString -> ParserState -> ParserState updateState s state = case (B.unpack $ head fields) of "M" -> updateStateMethod fields state "E" -> updateStateException fields state "C" -> updateStateEntry fields state "R" -> updateStateExit fields state where fields = B.splitWith (== ' ') s updateStateMethod :: [B.ByteString] -> ParserState -> ParserState updateStateMethod (_:methodId:methodName:_) state = state { methodMap = M.insert (readInteger methodId) methodName (methodMap state) } updateStateException :: [B.ByteString] -> ParserState -> ParserState updateStateException _ state = state updateStateEntry :: [B.ByteString] -> ParserState -> ParserState updateStateEntry (_:ss) state = {-Debug.Trace.trace ("before: " ++ (show state) ++ "\nafter: " ++ (show newstate)) $-} newstate where newstate = state { methodStack = updateMap thread (methodStack state) (\x y -> Just (x:y)) (pre state, 0, method) , pre = ((+1) $! (pre state)) } method = mkMethod (Prelude.map B.unpack ss) thread = Method.thread method updateStateExit :: [B.ByteString] -> ParserState -> ParserState updateStateExit (_:ss) state = {-Debug.Trace.trace ("before: " ++ (show state)) $-} case updateMethod m (Prelude.map B.unpack ss) of Just um -> state { methodStack = M.update (\x -> Just (tail x)) thread (methodStack state) , methodQueue = updateMap thread (methodQueue state) (\x y -> Just (x:y)) (pre_, post state, um) , post = ((+1) $! (post state)) } Nothing -> error $ "Top of the stack is mismatching! Expected " ++ (show m) ++ " yet got " ++ (show ss) ++ "\n" ++ (show state) where method = mkMethod (Prelude.map B.unpack ss) thread = Method.thread method (pre_, _, m) = case M.lookup thread (methodStack state) of Just stack -> head stack Nothing -> error $ "Method stack has not been found for thread " ++ (show thread) ++ " -> fields: " ++ (show ss) updateMap key map f value = case M.member key map of True -> M.update (f value) key map False -> M.insert key [value] map As you can see, the state is updated for each entry, a stack being maintained with methods we've seen up to now, and a list with methods that have received both pre and post order numbers, and of which both the entry and exit point have been parsed. I am using a ByteString, because using a plain String is causing the program to grab far too much heap. The mkMethod yields a Method like this: data Method = Method { mid :: Integer , thread :: Integer , instruction_entry :: Integer , instruction_exit :: Integer } deriving (Eq, Show) eM = Method 0 0 0 0 mkMethod :: [String] -> Method mkMethod s = let [_thread, _id, _entry] = take 3 $ map (read :: String -> Integer) s in [_thread, _id, _entry] `seq` Method { mid = _id , thread = _thread , instruction_entry = _entry , instruction_exit = 0 } updateMethod :: Method -> [String] -> Maybe Method updateMethod (Method mid thread instruction_entry instruction_exit ) s | thread == _thread && mid == _id = _exit `seq` Just Method { mid = mid , thread = thread , instruction_entry = instruction_entry , instruction_exit = _exit } | otherwise = Nothing where [_thread, _id, _exit] = take 3 $ map (read :: String -> Integer) s Any suggestions for improving this code? Thanks, Andy

2 2

help with creating a DAG?
by David Roundy 09 Jul '06

09 Jul '06

Hi all, I'm wanting to create a data structure to hold a directed acyclic graph (which will have patches represented by edges), and haven't yet been able to figure out a nice representation. I'd like one that can be reasoned with recursively, or as closely to recursively as possible. The problem is one of dependency relations between darcs patches, and "normally" reduces to a simple tree, with conflict resolution patches bringing branches of the tree back together. Trees I know how to handle intuitively and elegantly, but DAGs are a whole different question. I looked for papers, and there was one on "an initial-algebra approach to DAGs" that looked promising, but I'm afraid I wasn't able to fully understand it, and it is able to describe more complicated DAGs than I'd like to support. Anyhow, any suggestions from persons with experience with this sort of thing would be great. These are getting to be data structures that are more complicated than anything I'm comfortable with. :( -- David Roundy

4 4