September 2006 - Haskell-Cafe

parsing long numbers
by Andrea Rossato 15 Sep '06

15 Sep '06

Hello! I'm trying to learn parsing and parser combinations in Haskell, using, as usual, Wadler's Monads in Functional Programming as my text book. Everything works fine except for a small but annoying problem related to "read". I'm sure it must be something easy, some kind of stupid faq. Still I'm not able to find a way out. I created a simple parser and made it an instance of monad and MonadPlus. I then created "iterateP" to combine recursive parsers, and "filterP" to apply some filters. Then I created a function "number", to parse numbers. This function returns a string and works fine. But I wanted to have integers back from parsing. So I created a filter, "digitS", and a new parser for numbers, "number1", that applies recursively digitS and should be returning an Int using "read". The problem is that, when I run it with strings containing a number more then 10 digit long, I get unexpected integers back: *Main> runP number1 "1234567890 and the rest" [(1234567890," and the rest")] *Main> runP number1 "12345678901 and the rest" [(-539222987," and the rest")] Obviously if I use Parsec I can parse that number perfectly. So I tried with another approach: "number2" recursively applies a filter, "digitI", that returns an Int. asNumber is a function that takes a list of single digit integers and returns the corresponding integer. *Main> runP number2 "12345678901 and the rest" [(Just 1234567890," and the rest")] *Main> runP number2 "12345678901 and the rest" [(Just (-539222987)," and the rest")] The very same result. Can you please help me understand why I seem not to be able to get the number I'd like to get? As I said, I think I'm missing something that must be pretty obvious, but still I cannot see it! Thanks for your kind attention. Andrea ps: sorry for such a long message. Moreover, here's the code: module Main where import Control.Monad import Data.Char newtype M a = S {unpack :: String -> [(a,String)]} instance Monad M where return a = S $ \s -> [(a,s)] m >>= f = S $ \s -> [(b,z) | (a,y) <- unpack m s, (b,z) <- unpack (f a) y] instance MonadPlus M where mzero = S $ \x -> [] mplus a b = a `bchoice` b bchoice (S m) (S m1) = S $ \s -> case m s of [] -> m1 s other -> other iterateP m = do { a <- m ; b <- iterateP m ; return (a:b) } `mplus` return [] filterP p = S (\xs -> case xs of [] -> [] (x:xs') -> if p x then [(x,xs')] else []) number = do { a <- filterP isDigit ; b <- number ; return (a:b) } `mplus` return [] digitS = do a <- filterP isDigit return a number1 :: M Int number1 = do a <- iterateP digitS return (read a) -- a different approach maybeAdd a b = do x <- a y <- b return (x + y) asNumber :: [Int] -> Maybe Int asNumber [] = Nothing asNumber (x:[]) = Just x asNumber (x:xs) = Just (x * 10 ^ length xs) `maybeAdd` asNumber xs digitI = do a <- filterP isDigit return $ ord a - ord '0' number2 :: M (Maybe Int) number2 = do a <- iterateP digitI return $ asNumber a runP (S f) = f

2 1

evaluate vs seq
by Michael Shulman 15 Sep '06

15 Sep '06

The GHC documentation says that (evaluate a) is not the same as (a `seq` return a). Can someone explain the difference to me, or point me to a place where it is explained? Mike

4 13

Optimization problem
by Rohan Drape 15 Sep '06

15 Sep '06

> > splitStreams [(3,x),(1,y),(3,z),(2,w)] > [(3,[x,z]),(1,[y]),(2,[w])] [snip] > Furthermore it should work on infinite lists. It can't eat the whole > list before producing any output. This doesn't seem to make sense? Only at the end of the list can you know that you've collected all the events for each channel. If you output anything before scanning to the end, you'd not know if there were perhaps more events on that channel? You could accumulate only over a window, which would produce values on an infinite input, though the output list could have multiple packets for each channel. splitterW 3 [(3,x),(1,y),(3,z),(2,w),(3,v)] > [(3,[x,z]),(1,[y]),(2,[w]),(3,[v])] Or accumulate until either there are 'n' messages on a channel or the end of the list is reached? splitterN 3 [(3,x),(1,y),(3,z),(2,w),(3,v),(1,u),(3,t)] > [(3,[x,z,v]),(1,[y,u]),(2,[w]),(3,[t])] Regards, Rohan

3 4

Anonymous types
by Thomas Conway 15 Sep '06

15 Sep '06

Hi all, Is there any deep and meaningful reason why Haskell doesn't have anonymous discriminated union types? I'm thinking of an example like: data Amount = Amount Integer (Mg|G|Kg|T) Now this particular case is perhaps unconvincing - a seperate Units type would be quite sensible, however I'm thinking of translating ASN.1 definitions into Haskell. ASN.1 allows SEQUENCE (record types) and CHOICE (discriminated unions) as a kind of type constructor. Not having to invent names for anonymous SEQUENCE and CHOICE types would be nice. T.

2 1

Bit string
by Thomas Conway 15 Sep '06

15 Sep '06

Hi all, I'm doing some work with ASN.1, and I'm thinking about how to represent the type "BIT STRING". The obvious, and inefficient representation would be > type BitString = [Bool] A reasonable sparse representation might be > type BitString = [Integer] where the integers represent the positions of the non-zero bits, but other implementations (e.g. C & C++ based ones) mostly seem to use dense representations, and there are certain predictability advantages to be had by following existing implementations in this regard. But given that a value of type BIT STRING is allowed to have leading 0 bits, which have no semantic effect, another representation would be > type BitString = [Word64] (I'm a modern type, and believe in 64bit computing ;-), but you could use Word32 if you liked). However, after a few moments' consideration, I realized, that if I was going to use a representation like that, I could probably use > type BitString = Integer which already has [I assume] a carefully optimized implementation. Also, it ends up being significantly more strict than a list representation, which is probably a good thing in most situations. My question for all present is: Have I missed either a problem with using Integer, or have I overlooked a better representation? T.

5 5

ambiguous partially defined type problem
by Maarten 14 Sep '06

14 Sep '06

Dear all, For a project involving I use some partially defined node (in this case a simple record, in my project state transformers) in which the defined part is common to all nodes, and the custom part is different for each node. They have to become anonymous so I can put them in a list of connections from each node to another. For some reason GHC complains of 'ambigous type variable' in the code below. The thing is, part of the code may be undefined, but since I'm (explicitly) not using that part, why would GHC care? Are there other solutions to this problem? Any pointers or comments appreciated. Thanks. Maarten (This code is just some dummy code that contains the essence of the problem. I posted the complete code with piggy bagged state transformers in active objects on haskell(a)haskell.org, but that is rather long and this seems to be the correct mailing list). -- data structure with custom and common part data Node cust = Node cust Common deriving (Show,Typeable) -- anonymous data structure to put use in list data AN = forall ar. (Show ar, Typeable ar) => AN ar instance Show AN where show (AN an) = "AN (" ++ show an ++ ")" -- common part data Common = Common Integer deriving (Show,Typeable) data Custom = Custom Integer deriving (Show,Typeable) data Custom2 = Custom2 Integer deriving (Show,Typeable) -- extract common part, ignoring type of custom part getCommon :: forall gc. (Node gc) -> Common getCommon (Node cust com) = com main = do let a = AN (Node (Custom 5) (Common 10)) let b = case a of (AN a') -> getCommon (case (cast a') of Just a'' -> a'') putStrLn $ "ok:" ++ show b

3 2

program execution and laziness
by Tim Newsham 14 Sep '06

14 Sep '06

I'm having a problem with program execution in win32 which seems to be tied to laziness. The function I'm using is: runCmd cmd outdir dir base ext = do let argv = words cmd (i,o,e,p) <- runInteractiveProcess (head argv) (drop 1 argv) Nothing Nothing hClose i out <- hGetContents o -- print out x <- waitForProcess p hClose o hClose e case x of ExitSuccess -> return 0 (ExitFailure n) -> return n this is hanging indefinitely when I run it in win32. If I add in the print statement (commented out above) it works fine! So I can only imagine that waitForProcess is hanging when I haven't drained the stdout stream. How can I force hGetContents to be strict (or at least to completely process the stream prior to the waitForProcess command)? Tim Newsham http://www.thenewsh.com/~newsham/

4 3

Re: [Haskell-cafe] Slow IO
by Daniel Fischer 14 Sep '06

14 Sep '06

Am Montag, 11. September 2006 17:44 schrieben Sie: > Daniel Fischer wrote: > > > Try Don Stewart's ByteString library > > > > -- and some data that made the programme segfault before now run in a > > couple of seconds. > > But that shouldn't happen! Segfaults aren't performance problems, but > errors. So your program contained a bug (lazyness where it isn't > useful, I suspect), and ByString is hiding it. Maybe I've misused the word segfault. What happened is: The programme consumed more and more memory (according to top), kswapd started to have a higher CPU-percentage than my programme, programme died, system yelling 'Speicherzugriffsfehler', top displays 'kswapd<defunct>'. I believe that means my programme demanded more memory than I have available (only 256MB RAM + 800MB swap). Is that a segfault or what is the correct term? That is probably due to (apart from the stupidity of my IO-code) the large overhead of Haskell lists. So the chunk of the file which easily fits into my RAM in ByteString form is too large as a list of ordinary Strings. However the problem might be too little lazyness, because if I explicitly read the file line by line, memory usage remains low enough -- but ByteString is *much* faster anyway. > > > So even if we just counted newlines, we would have to scan 1,700 million > > (1.7*10^9) chars per second. > > Could any ordinary computer of today do that, using whatever language? > > That rate should be no problem for a 2GHz machine. However, a 200MHz 64 > bit wide bus won't deliver the data fast enough and it is 50x as much as > the best hard disks could deliver in optimal circumstances. I guess, > most of the test cases are a lot smaller than your guesstimate. > I suppose so, too, but not knowing the test data, I assumed a bad case (uniform distribution of line-lengths and test-case-size in the specified range). > > Udo. Bulat: > are you mean arithmetic or geometric average? ;) I meant 'expected value'. If X_i are independent random variables uniformly distributed on [0 .. k], Y is a random variable (independent from the X_i) uniformly distributed on [1 .. n] and Z is the sum of the first Y of the X_i, then the expected value of Z is (n+1)*k/4. So we might call that a weighted arithmetic average, I suppose. Cheers, Daniel -- "In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt." -- Blair P. Houghton

6 10

Optimization problem
by tpledger＠ihug.co.nz 13 Sep '06

13 Sep '06

Magnus Jonsson wrote: [...] > but your example fails on infinite lists [...] > take 2 $ snd $ head $ splitStreams (map (\x -> (0 ,x)) [1..]) Any approach, even sieving, will struggle with infinite lists, won't it? (take 2 . snd . head . splitStreams) [(i, i) | i <- [0..]] Regards, Tom

2 1

Re: [Haskell-cafe] Weak pointers and referential transparency???
by tpledger＠ihug.co.nz 13 Sep '06

13 Sep '06

Brian Hulley wrote: > tpledger(a)ihug.co.nz wrote: [...] > > My reading of the semantics > > (http://haskell.org/ghc/docs/latest/html/libraries/base/System-Mem-Weak.html…) > > is that you can be sure the proxy *object* is gone. > > My problem is that I don't know what to make of the word > "object" in the context of Haskell ie when can I be sure > that a value is actually being represented as a pointer > to a block of memory and not stored in registers or > optimized out? Or is the compiler clever enough to > preserve the concept of "object" despite such > optimizations? I had been designing my Model/Proxy data > types with the Java notion of "everything is a pointer to > an object" but is this always correct relative to Haskell > as a language or is it just a consequence of the current > GHC implementation? In the context of System.Mem.Weak, but not necessarily GHC, we're concerned solely with garbage collection of heap objects. So yes, that's Java-like. AFAIK. An example of something outside that context is a GHC Int# (unboxed Int). It never inhabits the heap, and isn't allowed to be passed to a function where a polymorphic parameter is expected (such as mkWeak). Regards, Tom

1 0