January 2003 - Haskell-Cafe

Why no findM ? simple Cat revisited
by Ahn Ki-yung 11 Nov '03

11 Nov '03

Simple Cat (revisitied) \begin{code} import IO findM f [] = return Nothing findM f (x:xs) = do { v <- x; if f v then return (Just v) else findM f xs } isLeft (Left _) = True isLeft _ = False main = findM (isLeft) (hCat stdin) where hCat h = try (hGetLine h) : hCat h \end{code} This is my answer for the question of my own, which is posted a couple There are mapM, filterM in the Haskell 98 Standard Library. But why no findM there ? As you can see from simple cat, it seems quite useful. I think fildM should be added to the module Monad. -- Ahn Ki-yung

5 8

splatterhunks
by William Lee Irwin III 22 Apr '03

22 Apr '03

-- This program takes patch filenames as arguments and splits the patch -- files up on a hunk-by-hunk basis. I have found this useful for Linux -- kernel development, and perhaps others might find it useful in -- similar contexts where patches are the primary method of communication. module Main where import System import List main = getArgs >>= mapM_ splatterHunkFile splatterHunkFile file = mapM_ (\(f,ss) -> writeFile f (unlines ss)) . zip (map (((reverse . takeWhile (/= '/') . reverse $ file)++).("-"++).show) [1..]) . splatterHunks =<< readFile file splatterHunks ss = map (map unlines) $ zipWith (\s -> map (s:)) (map head . (splitList "diff") $ lines ss) (map (splitList "@@") . (splitList "diff") $ lines ss) splitList prefix ss = map ($ss) $ zipWith (\m n -> (if n >= 0 then take (n - m) else id) . drop m) (map fst . filter (\(n,s) -> isPrefixOf prefix s) $ zip [0..] ss) (tail (map fst . filter (\(n,s) -> isPrefixOf prefix s) $ zip [0..] ss) ++ [-1])

1 1

comonads, io
by peter＠premise.demon.co.uk 05 Apr '03

05 Apr '03

I came across an interesting paper "Codata and comonads in Haskell" by Richard Kieburtz, and some other work by Alberto Pardo on comonads. Kieburtz proposes an OI comonad, as an alternative to (or something alongside?) the IO monad. Just for reasons of symmetry, it's natural to wonder if they aren't as pervasive in functional programs as monads. Frustratingly, I can't seem to grasp the intuition. I'm aware that the state-monad s->(s,a) has a dual state-in-context comonad (s,s->a). How does the side-effect manifest itself? The (ineffective) hints the authors give revolve around the idea that side-effects "derive" from the context of a program. Any other hints? Are comonads especially appropriate for programming systems that react to changes in their environment? Is an object of OI type something like a program to react to events? I can't make the slightest sense of Kieburtz's OI co-monad, with commands like coGetChar :: OI Handle -> Char. Peter Hancock

4 6

Global variables?
by pavel＠joker.botik.ru 03 Feb '03

03 Feb '03

Hello, Is it even possible to make a "global variable" in Haskell? If yes, how? Thanks. -- Zhbanov Pavel

8 7

RE: Problem with backtracking monad transformer
by Guest, Simon 02 Feb '03

02 Feb '03

Hi, > On Thu, Jan 30, 2003 at 01:55:50PM -0000, Guest, Simon wrote: > > > I'm trying to make a backtracking state monad using Ralf Hinze's > > backtracking monad transformer. My problem is that it > > won't backtrack very far. > > > > Suppose I try ( a >> b ) `mplus` c. > > > > If b fails, it should try c, but it doesn't rewind past a. Andrew Bromage wrote: > > I've compared it with my own > well-tested implementation and it seems identical modulo renamings. The similarity is explained by the fact that I looked at your example on the Haskell Wiki as well as Ralf's paper, so thanks for that useful page. > > In case you want to compare: > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/hfl/hfl/mtl/ I will have a look at try to see what I am doing wrong. > > I didn't follow the rest of the code, so I suspect the problem is > elsewhere. One place to look is here: > > > -- backtracking state monad > > -- > > type NDSM st a = BACKTR (SM st) a > > You may have meant to stack the monad transformers in a different > order. This bit I don't understand. I only have one monad transformer, which I use to transform my SM monad. I have an uneasy feeling that my observe is in the wrong place (passed to runSM), but again, I can't see what else I should have done. Thanks for the assurance, but I'm still head scratching for now. cheers, Simon

2 1

Re: Global variables?
by Jon Cast 02 Feb '03

02 Feb '03

Nick Name <nick.name(a)inwind.it> wrote: > On Fri, 31 Jan 2003 07:47:43 +0000 > Glynn Clements <glynn.clements(a)virgin.net> wrote: > > The usual fudge is: > > import IORef > > import IOExts > > globalVar :: IORef Int > > globalVar = unsafePerformIO $ newIORef 0 > I see in the documentation of unsafePerformIO that no one makes > guarantees about the order in wich unsafePerformIO arguments are > performed (especially they don't have to be executed BEFORE main), so > this trick should not be adviced as a general practice; it should be > pointed out that it works in GHC but could not work in other > compilers. English nit: I think you mean ``could fail in other compilers'': it's not really impossible for the trick to work in other compilers than GHC. Otherwise, though, see my other post on this subject: unsafePerformIO will perform its action when the variable is accessed, so you can't write a Haskell program which differentiates between what any compiler actually does and running the variable allocations before main. > Vincenzo > -- > Fedeli alla linea, anche quando non c' Quando l'imperatore > malato, quando muore,o dubbioso, o perplesso. Fedeli alla linea > la linea non c'. [CCCP] Jon Cast

3 2

Re: Global variables?
by Jon Cast 02 Feb '03

02 Feb '03

Ralf Hinze <ralf(a)informatik.uni-bonn.de> wrote: > > Pavel G. Zhbanov wrote: > > > Is it even possible to make a "global variable" in Haskell? If > > > yes, how? > > The usual fudge is: > > import IORef > > import IOExts > > > > globalVar :: IORef Int > > globalVar = unsafePerformIO $ newIORef 0 > > However, beware of creating more than one "global variable" of the > > same type. If you enable optimisation, common subexpression > > elimination may result in both names referring to the same IORef. > John Hughes wrote a nice pearl on the subject, see > http://www.math.chalmers.se/~rjmh/Globals.ps This paper claims ``unsafePerformIO is unsafe''. That's not actually true in the sense meant; unsafePerformIO merely has safety pre-conditions that the compiler can't check. However, there's nothing wrong with using it (or wrapping it) as long as the preconditions are checked. In fact, IMO, it's /better/ to use unsafePerformIO in a common case like this, because exactly when the preconditions are satisfied will be much better understood. The precondition (proof obligation) of unsafePerformIO is that the order in which unsafePerformIOs are performed cannot affect the outcome of the program. However, in this case, ordering doesn't matter: the only side effect is allocation of a new IORef, and IORefs are sufficiently opaque we don't care (or really know) about un-allocated IORefs while the only case we care about the now-allocated IORef is when we de-reference it. But, that forces the IORef, which executes the unsafePerformIO. So, whenever we access the variable, it is allocated. Therefore, the outcome of the program (regardless of the order of evaluation) is the same as if all such global variable declarations are executed before main begins executing. So, the outcome is independent of the order of evaluation. There you go: the precondition of unsafePerformIO is satisfied, so the usage is safe. > Cheers, Ralf Jon Cast

2 1

Re: Global variables?
by Jon Cast 31 Jan '03

31 Jan '03

Glynn Clements <glynn.clements(a)virgin.net> wrote: > Pavel G. Zhbanov wrote: > > Is it even possible to make a "global variable" in Haskell? If yes, > > how? > The usual fudge is: > import IORef > import IOExts > globalVar :: IORef Int > globalVar = unsafePerformIO $ newIORef 0 > However, beware of creating more than one "global variable" of the > same type. If you enable optimisation, common subexpression > elimination may result in both names referring to the same IORef. Is this true? It seems wrong---I don't think expressions involving unsafePerformIO should be combined, for precisely this reason. Even if it is true, though, the following kludge should work: > {-# NOINLINE mkGlobalVar #-} > mkGlobalVar :: String -> alpha -> IORef alpha > mkGlobalVar name value = usafePerformIO (newIORef value) > globalVar = mkGlobalVar "globalVar" 0 This ensures that no common sub-expression elimination will be performed. > -- > Glynn Clements <glynn.clements(a)virgin.net> Jon Cast

1 0

Now solved [was RE: Problem with backtracking monad transformer]
by Guest, Simon 31 Jan '03

31 Jan '03

Andrew Bromage wrote: > > You may have meant to stack the monad transformers in a different > > order. I finally understand. This was exactly my problem. I had to discard my state monad, and use a state monad transformer on the simple backtracking monad (not the backtracking monad transformer on the state monad). Now it works fine (of course). Thanks for the help. cheers, Simon

1 0

Nine open CSE positions at Chalmers
by Patrik Jansson 31 Jan '03

31 Jan '03

The School of Computer Science and Engineering (at Chalmers Univ. in Gotheburg, Sweden) announces 9 open positions (teaching+research): http://www.cse.chalmers.se/doit/doiteng/vacancies/positions.html Apply or spread the word! (List relevance: Many of us use Haskell both in teaching and in research.) /Patrik PS. From my point of view, Haskellers with a background in Software Engineering / Information systems / Human Computer Interaction etc. are extra welcome!

1 0