September 2004 - Haskell-Cafe

Stack overflow in ghci
by Ron de Bruijn 02 Sep '04

02 Sep '04

I have an expression that gives a stack overflow in ghci (official Debian unstable CVS version)) when I evaluate it. The expression doesn't use more than 150MB of memory (I have more). How can I make sure the stack overflow doesn't happen? There are no strictness flags in my program. But I use DData Maps(I don't know whether they are implemented strict). I also don't know whether strictness/lazyness has anything do to with it. *SomeModule> test *** Exception: stack overflow (148.67 secs, 250825284 bytes) Sometimes I get a negative number of bytes. I heard of the +RTS option. I used: ghci SomeModule.hs -someoptions +RTS -K1500000, but this doesn't seem to have any effect. I think there should be someother option to change it? Thanks in advance, Ron de Bruijn __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail

2 2

Re: [Haskell-cafe] Implementing tryReadMVar
by MR K P SCHUPKE 02 Sep '04

02 Sep '04

>do e <- isEmptyChan ch -- is the channel empty? > case e of > True -> processFifo > False-> readChan ch >>= highPriorityOrPush >Now there is danger of blocking on the readChan. Erm, but it does not matter if the readChan blocks... This is specifically for the case where there is multiple threads writing and one reading... With multiple reading threads... well it depends on the plumbing, you could have one channel per reading thread, or one channel with a single thread looking ahead for high priority events, and then instead of a FIFO, another channel going to the worker threads that just read events: do e <- readChan ch if e highPriority then process e else writeChan ch2 e Keean.

1 0

Implementing tryReadMVar
by Einar Karttunen 02 Sep '04

02 Sep '04

Hello Is it possible to implement an operation like tryReadMVar :: MVar a -> IO (Maybe a) in a good fashion? The semantics should be "Read the value of the MVar without taking it if it is filled, otherwise return Nothing". There are several easy and flawed implementations: tryReadMvar mv = do e <- isEmptyMVar mv case e of True -> return Nothing False-> readMVar mv >>= return . Just This does not work because there can be a thread switch between the isEmpty and readMVar. tryReadMVar mv = do mc <- tryTakeMVar mv case mc of Nothing -> return mc Just v -> putMVar mv v >> return mc Now this can block on the putMVar if there was a thread switch and someone filled the MVar behind our back. Using tryPutMVar does not help much as it just creates another race condition: tryReadMVar mv = do mc <- tryTakeMVar mv case mc of Nothing -> return mc Just c -> tryPutMVar mv v >> return mc Consider what happens if the tryPutMVar fails: -- read till we get the value with foobar in the middle loopTill mv = do foobar mc <- tryReadMVar mv case mc of Nothing -> loopTill mv Just v -> return v maybe (loopTill mv) process (tryReadMVar mv) error = do mv <- newEmptyMVar forkIO (mapM_ (\i -> putMVar mv i) [1..10]) mapM_ (\_ -> loopTill mv >>= print >> takeMVar mv >>= print) [1..10] If a tryPutMVar fails, then there will be less than ten values to read which will make the process block in takeMVar. This seems quite straightforward in C with GHC (might be wrong in the SMP case with locking?): tryReadMVarzh_fast { W_ mvar, info; /* args: R1 = MVar closure */ mvar = R1; info = GET_INFO(mvar); if (info == stg_EMPTY_MVAR_info) RET_NP(0, stg_NO_FINALIZER_closure); RET_NP(1, vStgMVar_value(mvar); } What is the best way to do this? - Einar Karttunen

2 4

Re: [Haskell-cafe] Implementing tryReadMVar
by MR K P SCHUPKE 02 Sep '04

02 Sep '04

>might be a reason to want to prefer one event over another. You can still use a single channel... If you read all pending events on the channel into a FIFO (lazy list) then you can check for high priority events on read, and then deal with the next item on the top of the FIFO... something like the following (in pseudo code) while channel not empty read next event if event high priority process now else queue event in FIFO process first event in FIFO So inbetween processing low priority events we check ahead for any high priority ones... This could be extended with multiple FIFO's to deal with multiple priority levels... but this ensures all events are dealt with sequentially (if out of order)# Keean.

2 1

Re: [Haskell-cafe] Implementing tryReadMVar
by MR K P SCHUPKE 01 Sep '04

01 Sep '04

>tryReadMVar mv = do mc <- tryTakeMVar mv The normal reason people want tryRead is to do something like unix's 'select' function, where you want to wait on one of several signals... In my opinion it is better to do this with a _single_ channel and have one thread taking from the channel, whilst all sources of the 'events' write to the same channel... so the refactoring would be like: data Event = Even1 | Event2 | Event3 ... c <- newChan forkIO (...) a <- readChan c case a of Event1 -> ... Event2 -> ... Keean.

2 1

Haskell Naming Conventions ?
by Koray Can 01 Sep '04

01 Sep '04

Hi, I am new to haskell. One of the things that struck me odd from the very beginning was the names of things. At my workplace (where we use imperative languages), we abide by standards such as this: http://www-106.ibm.com/developerworks/library/ws-tip-namingconv.html Such conventions are debatable, but I believe some of them are worthy of applying. "ShowS" and "shows" do not have the same type, I know, but I read them as the same word. Similarly, fractional is "Fractional", but numeric is just "Num". There are "seq", "sequence" and "sequence_", etc. In The Gentle Introduction to Haskell, the author states: "...We use the term /error/ for /_|_/: a condition which cannot be recovered from such as non-termination or pattern match failure. Exceptions, on the other hand, can be caught and handled within the I/O monad...." Then he goes on to say that the data type's name is IOError (not IOException, as I was expecting.) I can imagine once one gets used to them, they don't pose any problems. Nevertheless, while I still learn, these names are quite awkward for me to read and talk about haskell. I searched the mailing list archives for a similar discussion, but I couldn't fine one. Is there a reason why things are named in such a way that conflicts with what's being followed for other languages ? Thanks for your replies.

2 1

RE: [Haskell-cafe] Higher-order unification
by Simon Peyton-Jones 01 Sep '04

01 Sep '04

| Yeah, here's a program which causes GHC to hang on compilation, but | causes no problem for hugs. Does this qualify as higher-order unification? | | newtype X a = X (X a -> a) | | selfapp :: X a -> a | selfapp self@(X f) = f self It's a documented bug in GHC. http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs.html Nothing to do with h-o unification Simon

1 0