- Haskell-Cafe - Haskell.org

linear logic
by Vasili I. Galchin 23 Feb '11

23 Feb '11

Hello, What is the category that is used to interpret linear logic in a categorical logic sense? Thank you, Vasili

5 4

monadic plumbing
by Alberto G. Corona 22 Feb '11

22 Feb '11

Recently I had to navigatate trough data structures chained with mutable referenes in th STM monad. The problem is that their values are enveloped in Either or Maybe results. functional compositions in the Either of Maybe , or list monads are not possible when the values are embedded inside effect monads (i.e. STM or IO) . I tried to find some trick to handle it. to summarize, given: foo, : a -> m (Maybe b) bar : b -> m (Maybe c) baz : c -> m (Maybe d) how to compose foo bar and baz? Or, at least, Are something out there to handle it in the less painful way?. I solved the generalized problem (chaining any double monadic combination) with a sort of monadic connector that acts as a " double monadic" operator >>>>== so that return. return (x :: a) >>>>== foo >>>== bar >>>== baz can be possible. Although I don't know if it is the best solution. I wonder why nobody has written about it before: class (Monad m, Monad n) => Bimonad m n where (>>>=) :: n a -> (a -> m(n b)) -> m(n b) (>>>>==) :: (Bimonad m n) => m (n a) -> (a -> m(n b)) -> m (n b) (>>>>==) x f = x >>= \y -> y >>>= f x >>>> f = x >>>>== \ _-> f infixl 1 >>>>==, >>>> The instance for handling the Maybe monad under any other monad is very similar to the definition of the "normal" monad: instance (Monad m) => Bimonad m Maybe where Just x >>>= f = f x Nothing >>>= _ = return $ Nothing

7 6

Re: [Haskell-cafe] iteratee-compress space leak?
by Michael A Baikov 22 Feb '11

22 Feb '11

-----Original Message----- > Hi Maciej, > > Thanks for looking in to this. > > > After looking into problem (or rather onto your code) - the problem have > > nothing to do with iteratee-compress I believe. I get similar behaviour > > and results when I replace "joinIM $ enumInflate GZip > > defaultDecompressParams chunkedRead" by chunkedRead. (The memory is > > smaller but it is due to decompression not iteratee fault). > > > > This is due to "printLines". Whether it's a bug depends on what the correct > behavior of "printLines" should be. > > "printLines" currently only prints lines that are terminated by an EOL > (either "\n" or "\r\n"). This means that it needs to hold on to the entire > stream received until it finds EOL, and then prints the stream, or drops it > if it reaches EOF first. In your case, the stream generated by "convStream > consChunk printLines" is just a stream of numbers without any EOL, where the > length is dependent on the specified block size. This causes the space > leak. > > If I change the behavior of "printLines" to print lines that aren't > terminated by EOL, the leak could be fixed. Whether that behavior is more > useful than the present, I don't know. Alternatively, if you insert some > newlines into your stream this could be improved as well. > > As a result of investigating this, I realized that > Data.Iteratee.ListLike.break can be very inefficient in cases where the > predicate is not satisfied relatively early. I should actually provide an > enumeratee interface for it. So thanks very much for (indirectly) > suggesting that. Actually i can give you full sorce code - it uses also attoparsec-iteratee. it leaks with iteratee-compress and works fine without it. Whole idea - get bytestring from access.log, convert it to stream of data object with usernames and bytes downliaded and then feed this stream into iteratee which will collect all data into one big Map ByteString Integer.

4 3

Faster timeout but is it correct?
by Bas van Dijk 22 Feb '11

22 Feb '11

Dear all, I wrote a faster implementation for System.Timeout.timeout but wonder whether it's correct. It would be great if someone can review the code. The implementation comes with a tiny Criterion benchmark: darcs get http://bifunctor.homelinux.net/~bas/bench_timeouts/ On ghc-7.0.1 with -O2 the following benchmark, which always times out, doesn't show a difference with the current timeout: timeout 1 (threadDelay 1000000) However the following benchmark, which never times out, shows nice speedups for both a non-threaded and a threaded version: timeout 1000000 (return ()) non-threaded: 3.6 faster threaded: 10.8 faster I suspect the reason why my timeout is faster is that I use only one 'catch' while the original uses two: handleJust and bracket. I have to admit that my implementation is more complex and more fragile than the original. That's why I'm not sure of it's correctness yet: newtype Timeout = Timeout Unique deriving (Eq, Typeable) instance Show Timeout where show _ = "<<timeout>>" instance Exception Timeout timeout :: Int -> IO a -> IO (Maybe a) timeout n f | n < 0 = fmap Just f | n == 0 = return Nothing | otherwise = do myTid <- myThreadId timeoutEx <- fmap Timeout newUnique uninterruptibleMask $ \restore -> do tid <- restore $ forkIO $ threadDelay n >> throwTo myTid timeoutEx let handle e = case fromException (e :: SomeException) of Just timeoutEx' | timeoutEx' == timeoutEx -> return Nothing _ -> killThread tid >> throwIO e mb <- restore (fmap Just f) `catch` handle killThread tid return mb If nobody proves it incorrect I will make a patch for the base library. Regards, Bas

7 32

Infinite types should be optionally allowed
by Job Vranish 22 Feb '11

22 Feb '11

There are good reasons against allowing infinite types by default (mostly, that a lot of things type check that are normally not what we want). An old haskell cafe conversation on the topic is here: http://www.nabble.com/There%27s-nothing-wrong-with-infinite-types!-td771373… However, I think infinite types should be allowed, but only with an explicit type signature. In other words, don't allow infinite types to be inferred, but if they are specified, let them pass. I think it would be very hard to shoot yourself in the foot this way. Newtype is the standard solution to situations where you really need an infinite type, but in some cases this can be a big annoyance. Using newtype sacrifices data type abstraction and very useful type classes like Functor. You can use multiparameter type classes and functional dependencies to recover some of the lost abstraction, but then type checking becomes harder to reason about and the code gets way more ugly (If you doubt, let me know, I have some examples). Allowing infinite types would fix this. I'm imagining a syntax something like this: someFunctionThatCreatesInfiniteType :: a -> b | b = [(a, b)] Thoughts? Opinions? Am I missing anything obvious? - Job

3 10

Is there something better than tags?
by Magnus Therning 22 Feb '11

22 Feb '11

I've been using haskellmode for vim for a while now and I'm really happy with it. It does however have some shortcomings. These are the things I find missing at times: 1. Fully functional go-to-definition. With that I mean that go-to-definition is aware of local definitions introduced in 'let' and 'where' clauses and ideally also for names bound in 'do' clauses. I've found there are several ways to generate a tags file, GHCi can generate them, and there are two tools for it, hasktags and hothasktags. haskellmode currently uses GHCi to generate tags. However, the limitation seems to be inherent in the tags format itself. AFAICS there is no way to get a fully functional go-to-definition with that format. 2. Retrieve type information for local defintions ('let', 'where', 'do'), and ideally also for sub expressions (like ':t filter (== 1)'. I believe haskellmode uses GHCi to get the type information out, but it is only able to get it for top-level definitions. Are there any options to address these two shortcomings in haskellmode? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus

3 4

#haskell-game & Haskellers Game Interest Group
by Korcan Hussein 22 Feb '11

22 Feb '11

Some of us interested in Haskell GameDev have formed chat room & Haskellers Interest Group, you can out find more info here. Just spreading the word around.

4 3

Re: [Haskell-cafe] Please review my Xapian foreign function interface
by Edward Z. Yang 21 Feb '11

21 Feb '11

Excerpts from Oliver Charles's message of Mon Feb 21 08:53:48 -0500 2011: > Yes, this is a concern to me as well. The only places I've used > unsafePerformIO is with Query objects, which I am mostly treating as > immutable data, and never exposing anyway to modify query > objects. That is a good way to start thinking about it. If there is an efficient mechanism for copying query objects, you can also implement "persistent update" (e.g. copy the structure and then mutate it). > However, what is better? Should I avoid taking this > risk/assumption of immutability and use this within the IO monad also? I > guess my biggest fear is that this entire library is only usable in the > IO monad, which from what I understand limits my ability to test easily. Don't take the risk: verify for yourself that there is no risk! Note that putting things in IO doesn't get you off the concurrency hook: things in IO can be run in different threads and you need to synchronize them. Indeed, as the Xapian faq states: If you want to use the same object concurrently from different threads, it's up to you to police access (with a mutex or in some other way) to ensure only one method is being executed at once. It is admittedly more annoying to test things in IO. One thing you can do is if database objects are completely isolated from one another (which seems to be the case) you can build up a custom monad for manipulating this object in a single-threaded and/or thread safe manner. I did something like this (actually, I needed to enforce more complex invariants about when what functions could get called), but unfortunately it was for work and the code hasn't been cleared for publication yet. Cheers, Edward

1 0

Re: [Haskell-cafe] iteratee-compress space leak?
by John Lato 21 Feb '11

21 Feb '11

Hi Maciej, Thanks for looking in to this. > From: Maciej Piechotka <uzytkownik2(a)gmail.com> > > On Fri, 2011-02-18 at 17:27 +0300, Michael A Baikov wrote: > > I am trying to play with iteratee making parser for squid log files, but > found that my code do not run in constant space when it tries to process > compressed log files. So i simplified my code down to this snippet: > > > > import Data.ByteString (ByteString) > > import Data.Iteratee as I > > import Data.Iteratee.Char > > import Data.Iteratee.ZLib > > import System > > > > main = do > > args <- getArgs > > let fname = args !! 0 > > let blockSize = read $ args !! 1 > > > > fileDriver (leak blockSize) fname >>= print > > > > leak :: Int -> Iteratee ByteString IO () > > leak blockSize = joinIM $ enumInflate GZip defaultDecompressParams > chunkedRead > > where > > consChunk :: Iteratee ByteString IO String > > consChunk = (joinI $ I.take blockSize I.length) >>= return . show > > > > chunkedRead :: Iteratee ByteString IO () > > chunkedRead = joinI $ convStream consChunk printLines > > > > > > First argument - file name (/var/log/messages.1.gz will do) > > second - size of block to consume input. with low size (10 bytes) of > consumed blocks it leaks very fast, with larger blocks (~10000) it works > almost without leaks. > > > > So. Is it bugs within my code, or iteratee-compress should behave > differently? > > After looking into problem (or rather onto your code) - the problem have > nothing to do with iteratee-compress I believe. I get similar behaviour > and results when I replace "joinIM $ enumInflate GZip > defaultDecompressParams chunkedRead" by chunkedRead. (The memory is > smaller but it is due to decompression not iteratee fault). > This is due to "printLines". Whether it's a bug depends on what the correct behavior of "printLines" should be. "printLines" currently only prints lines that are terminated by an EOL (either "\n" or "\r\n"). This means that it needs to hold on to the entire stream received until it finds EOL, and then prints the stream, or drops it if it reaches EOF first. In your case, the stream generated by "convStream consChunk printLines" is just a stream of numbers without any EOL, where the length is dependent on the specified block size. This causes the space leak. If I change the behavior of "printLines" to print lines that aren't terminated by EOL, the leak could be fixed. Whether that behavior is more useful than the present, I don't know. Alternatively, if you insert some newlines into your stream this could be improved as well. As a result of investigating this, I realized that Data.Iteratee.ListLike.break can be very inefficient in cases where the predicate is not satisfied relatively early. I should actually provide an enumeratee interface for it. So thanks very much for (indirectly) suggesting that. Cheers, John L

1 0

PhD Studentships in Functional Programming
by Henrik Nilsson 21 Feb '11

21 Feb '11

Apologies for multiple copies. -- Henrik Nilsson School of Computer Science The University of Nottingham nhn(a)cs.nott.ac.uk

1 0