February 2009 - Libraries

IdentityT to transformers
by Henning Thielemann 12 Feb '09

12 Feb '09

Ross, thanks a lot for adding MaybeT! Unfortunately I have just another wish. In a parser I like to show by types whether the parser can fail or not. To this end I have a type parameter for a monad transformer that can be instantiated either by MaybeT or by IdentityT. The only problem is, that there is no IdentityT in transformers package, yet.

2 2

RE: MaybeT to transformers
by Sittampalam, Ganesh 12 Feb '09

12 Feb '09

Henning Thielemann wrote: > Sittampalam, Ganesh wrote: >> Henning Thielemann wrote: >>> What about adding the Maybe monad transformer as provided in MaybeT >>> package to the transformers package? >>> >>> The module name could be >>> Control.Monad.Trans.Maybe >>> which would also avoid conflicts with the MaybeT package. >> >> What MonadPlus instance will it get, if any? > > The one which is currently used by MaybeT: > > instance (Monad m) => MonadPlus (MaybeT m) where > mzero = MaybeT (return Nothing) > mplus x y = MaybeT $ do v <- runMaybeT x > case v of > Nothing -> runMaybeT y > Just _ -> return v > > > It is also the one I needed recently. I tend to agree that this is the right one to use, but I think care should be taken when adding this to what is/is expected to be a widely used package, as it could make it difficult for people who want the alternate behaviour, and it might imply a degree of standardisation/ canonicity that is not really justified. On the other hand, perhaps there are no real uses for the other one. Cheers, Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ==============================================================================

4 3

Newtype unwrapping in the FFI
by Simon Peyton-Jones 12 Feb '09

12 Feb '09

[This email concerns an infelicity in the FFI spec. I'm directing it primarily to the Haskell Prime mailing list, but ccing the libraries list so that people there know about the thread. I suggest that replies go to Haskell Prime only.] Consider this program (see http://hackage.haskell.org/trac/ghc/ticket/3008) module NT( N ) where newtype N = MkN Int module FFI where foreign import "f" :: N -> IO () Is module FFI OK? It would definitely be OK if N was defined in the module FFI: the FFI spec says that the compiler must automatically unwrap any newtype arguments. http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise3.html#x6-120003.2 But it's less clear when N is defined in another module *and* its representation isn't exported. The author of NT might believe that because N's representation is hidden, she can change it to, say data N = MkN Int without affecting the rest of the world. But she can't. This is a nasty failure of abstraction. It is, I believe the only way in which a client of a NT could be affected by N's representation, even though that representation is allegedly hidden. (ToDo: check on generalised newtype deriving.) This seems Bad to me. Indeed, the cause of the above bug report is that GHC's implementation assumes that the representation is fully hidden if the constructor is not exported, and does not expose the representation of N even to separately-compiled modules (at least when you are not using -O). But the point here is not what GHC stumbles on but what is supposed to happen. Maybe we should fix it. Proposal: * Clarify the spec to say that a newtype can only be automatically unwrapped if the newtype constructor (MkN in this case) is in scope It happens that a large set of types from Foreign.C.Types, such as CInt and friends, are exported without their constructors, so adopting this new rule would require us to change Foreign.C.Types to expose the representation of CInt and friends. (As it happens, nhc requires this already, so there's some #ifdeffery there already.) Simon

1 0

Proposal for Data.List.splitBy
by Marcus D. Gabriel 10 Feb '09

10 Feb '09

We seem to have not added any splitters such as splitBy or split to Data.List despite the discussions. Here is yet another perspective with the hope that it will make it. For the record, see the threads * http://www.haskell.org/pipermail/libraries/2004-July/thread.html#2342 * http://www.haskell.org/pipermail/haskell-cafe/2006-July/thread.html#16559 * http://www.haskell.org/pipermail/libraries/2008-January/thread.html#8922 see the article * http://www.haskell.org/pipermail/libraries/2006-October/006072.html and see the wiki page * http://haskell.org/haskellwiki/List_function_suggestions Essentially, I believe that the difficulty in choosing a splitter for Data.List comes from the fact that it does not take much of a problem to solve before a simple splitter is just not enough whereupon you should just use a FSM, Alex, or Parsec for example. A way forward would be to state a few meta-properties and properties up front and then see if this leads to a reasonable solution for the simple problems that just need a solution that is "good enough." I would suggest that 1. a set of splitter words should be small in number, 2. such a set should fit within the spirit of the List module of the Haskell 98 standard libraries, 3. it should pick up where break and span left off, and 4. the results coming from this set of splitter words should be unsplittable. I would argue that the above suggestions imply at least two words * splitBy :: (a -> Bool) -> [a] -> [([a], [a])] and * split :: [a] -> [a] -> [([a], [a])] such that splitBy takes a predicate p, e.g., (=='\n'), and a list xs and such that split takes a list of equivalent delimiters ds, e.g., " \t", and a list xs. The functions splitBy and split should at least have the follow properites. > (concatMap (\(x1, x2) -> x1 ++ x2) $ splitBy p xs) == xs > splitBy _ [] == [([],[])] > splitBy (\x -> False) xs == [(xs,[])] > splitBy (\x -> True) xs == [([],[x1]),([],[x2]),([],[x3]), ...] and > (concatMap (\(x1, x2) -> x1 ++ x2) $ split ds xs) == xs > split _ [] == [([],[])] > split [] xs == [(xs,[])] > split xs xs == [([],[x1]),([],[x2]), ([],[x3]), ...] where xs == x1:x2:x2:...:[]. Examples would be > splitBy (=='/') "/a/b" == [("","/"),("a","/"),("b","")] > splitBy (=='/') "//aa//bb" == > [("","/"),("","/"),("aa","/"),("","/"),("bb","")] > splitBy (=='\n') "\na\nb" == [("","\n"),("a","\n"),("b","")] > split xs xs == [([],[x1]),([],[x2]), ([],[x3]), ...] > split " \t" "a\tb \tc\t d " == > [("a","\t"),("b"," "),("","\t"),("c","\t"),(""," "),("d"," ")] > split "/" "/a/b" == [("","/"),("a","/"),("b","")] This leaves the one remaining "simple" case which is splitting using a list such as "\r\n" which splitBy and split cannot handle easily. This leads to * splitUsing :: (Eq a) => [a] -> [a] -> [([a], [a])] such that > (concatMap (\(x1, x2) -> x1 ++ x2) $ splitUsing xs xs') == xs' > splitUsing _ [] == [([] , [])] > splitUsing [] xs == [(xs , [])] > splitUsing xs xs == [([] , xs)] Examples would be > splitUsing "\r\n" "a" == [("a", "")] > splitUsing "\r\n" "\r\n" == [("" , "\r\n")] > splitUsing "\r\n" "a\r\n" == [("a", "\r\n")] > splitUsing "\r\n" "a\r\n\r\n" == [("a", "\r\n"), ("" , "\r\n")] > splitUsing "\r\n" "a\r\nb" == [("a", "\r\n"), ("b", "")] > splitUsing "\r\n" "a\r\nb\r\n" == [("a", "\r\n"), ("b", "\r\n")] Wrapping up, based on a sort of logical extension, you could imagine * splitWhere :: ([a] -> Bool) -> [a] -> [([a], [a])] but I believe that this fourth word is one too many, cute, but not necessary. If the above three splitter words are not enough, then I would say that you need a more powerful tool beyond the spirit of the Haskell 98 standard List module. Just to check, the Haskell 98 List.lines function would be defined as > lines98 xs = map fst $ split "\n" xs and proper lines' and unlines' functions would be > lines' :: String -> Either [String] [String] > lines' [] = Left [] > lines' xs = > let res = split "\n" xs > nul = (null.snd.last) res > in (if nul then Left else Right) $ map fst res > > unlines' :: Either [String] [String] -> String > unlines' exss = intercalate "\n" $ either (id) (++[[]]) exss such that > unlines' . lines' == id This is to say, (Right [String]) if the original xs ends in '\n' and (Left [String]) if it does not. For your review, the attached file Split.hs defines and documents splitBy, split, splitUsing, and splitWhere, and the attached file SplitProperties.hs defines tests for these same words. Finally, I would propose adding splitBy, split, and splitUsing to Data.List as three words that fit within the spirit of the Haskell 98 List module, take off where break and span leave off, are unsplittable, and are "good enough". Cheers, - Marcus -- Marcus D. Gabriel, Ph.D. Saint Louis, FRANCE http://www.marcus.gabriel.name mailto:marcus@gabriel.name Tel: +33.3.89.69.05.06 Portable: +33.6.34.56.07.75

7 21

Proposal #2998: Expose the internals of the network library to make it more extensible
by Johan Tibell 09 Feb '09

09 Feb '09

Hi all, In short, I propose that we export some of the internals of the network library in a new module to make it easier to write portable libraries on top of the library. I've added the full proposal, copied from Trac, below. The motivating example is network-bytestring which needs to marshall different socket related data types to support e.g. `sendmsg`. http://hackage.haskell.org/trac/ghc/ticket/2998 Discussion deadline: 2 weeks (non disruptive change) --- When creating new libraries on top of the network library it would be convenient if the library exposed some functions that hide platform variations so that the new libraries can be written in a portable manner. Take for example the currently un-exported pokeSockAddr function which marshalls a SockAddr into a sockaddr struct. This function would be useful when e.g. writing a binding for the sendmsg system call. However, it's not exported so libraries are forced to define their own version. This is unfortunate. I propose we add a new module, Network.Socket.Internal, to the network library, that exposes these portable marshalling functions. It might also be a good idea to expose some internal data representations in the same way bytestring currently does. People who write code that uses this internal do so knowing that there is a risk that the interface and data representations might change. I've written a patch that exposes some of the library's internal functions. There are still some documentation to write and perhaps a few more functions to expose but I think we should reach consensus on whether this is a good idea to begin with before continuing. Since this change isn't disruptive I propose a two week consideration deadline. Cabal package: http://johantibell.com/network-2.2.1.tar.gz Haddock: http://johantibell.com/network/doc/html/network/ --- Cheers, Johan

2 2

Djinn Doesn't Build
by Dominic Steinitz 08 Feb '09

08 Feb '09

> dom@linux-6ofq:~/djinn-2009.2.1> runghc Setup.lhs build > Preprocessing executables for djinn-2009.2.1... > Building djinn-2009.2.1... > [1 of 7] Compiling REPL ( src/REPL.hs, dist/build/djinn/djinn-tmp/REPL.o ) > > src/REPL.hs:18:17: > Ambiguous type variable `e' in the constraint: > `Control.Exception.Exception e' > arising from a use of `Control.Exception.catch' > at src/REPL.hs:(18,17)-(33,12) > Probable fix: add a type signature that fixes these type variable(s) > dom@linux-6ofq:~/djinn-2009.2.1> ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.10.1

2 2

Updates for Jan 24 - Feb 7
by Don Stewart 07 Feb '09

07 Feb '09

http://archhaskell.wordpress.com/2009/02/07/arch-haskell-news-feb-07-2009/ Due to a technical error, I lost the .xml for which packages were updated, however, we can establish that there are now 899 Haskell packages in Arch. Some noteworthy new packages: Full SDL bindings. http://archhaskell.wordpress.com/2009/02/07/sdl-bindings-for-haskell/ Happstack http://archhaskell.wordpress.com/2009/02/07/happstack/ LLVM http://archhaskell.wordpress.com/2009/02/07/llvm-bindings-for-haskell/ I also updated HDBC. -- Don

1 0

MaybeT to transformers
by Henning Thielemann 06 Feb '09

06 Feb '09

What about adding the Maybe monad transformer as provided in MaybeT package to the transformers package? The module name could be Control.Monad.Trans.Maybe which would also avoid conflicts with the MaybeT package.

4 3

Bug in Cabal?
by Dominic Steinitz 05 Feb '09

05 Feb '09

I couldn't seem to logon to the trac to report this. I'm working on windows (not linux as the chmod might suggest). zlib-0.5.0.0>runghc Setup.hs configure --package-db=..\..\ghc\ghc-6.10.1\fpf.package.conf --docdir=..\..\haskell_packages\doc\zlib-0.5.0.0 --libdir=..\..\haskell_packages --bindir=..\..\haskell_packages\bin Configuring zlib-0.5.0.0... zlib-0.5.0.0>runghc Setup.hs build Preprocessing library zlib-0.5.0.0... Building zlib-0.5.0.0... ghc-6.10.1\bin\ar.exe: creating dist\build\libHSzlib-0.5.0.0.a zlib-0.5.0.0>runghc Setup.hs install Setup.hs: ..\..\haskell_packages\doc\zlib-0.5.0.0\.copyFile920.tmp: copyFile: permission denied (Access is denied.) Cabal seesm to create certain things as read only. I can work around this by chmod a+w ..\ThirdParty\haskell_packages\zlib-0.5.0.0\ghc-6.10.1\include\* chmod a+w ..\ThirdParty\haskell_packages\doc\zlib-0.5.0.0\* rm ..\ThirdParty\haskell_packages\doc\zlib-0.5.0.0\* I suspect most people haven't tripped over this as once something is installed they don't tend to install it again. Dominic.

3 10

piping with System.Process.createProcess
by Claude Heiland-Allen 05 Feb '09

05 Feb '09

Greetings, I think I found a bug in the process package. GNU/Linux Debian Lenny ghc-6.8.2 process-1.0.1.1 The short version: UseHandle fails for input streams (subprocess can't read from it). The long version: > import System.Process > import System.IO (Handle, hGetLine, hPutStrLn, hIsEOF, hClose) > import System.Environment (getArgs) > import Control.Concurrent (forkIO, threadDelay) > import Control.Monad (forever, unless) Forward ------- A pipeline of processes defined in the "forwards" direction (where the next process's input handle is the previous process's output handle). > pipeForwards :: IO (Handle, Handle) > pipeForwards = do > (Just input, Just pipe, _, _) <- createProcess (proc "cat" []){ std_in = CreatePipe, std_out = CreatePipe } > (_, Just output, _, _) <- createProcess (proc "cat" []){ std_in = UseHandle pipe, std_out = CreatePipe } > return (input, output) Data would flow through this pipe from top to bottom, which I find to be intuitive. However, pipeForwards is broken; it fails with the message "cat: -: Resource temporarily unavailable". (The "cat" that fails is the "cat" with the UseHandle.) Backward -------- A pipeline of processes defined in the "backwards" direction (where the next process's output handle is the previous process's input handle). Data flows through this pipe from bottom to top, which I find to be more confusing. But at least it works. > pipeBackwards :: IO (Handle, Handle) > pipeBackwards = do > (Just pipe, Just output, _, _) <- createProcess (proc "cat" []){ std_in = CreatePipe, std_out = CreatePipe } > (Just input, _, _, _) <- createProcess (proc "cat" []){ std_in = CreatePipe, std_out = UseHandle pipe } > return (input, output) Scaffold -------- The main program pipes some data through one of the pipelines, depending on the command line arguments. > main :: IO () > main = do > args <- getArgs > (input, output) <- if null args then pipeForwards else pipeBackwards > forkIO $ reader output > forkIO $ writer input > mainLoop The reader thread will read all the lines from a handle and print them out. > whileNotM :: Monad m => m Bool -> m a -> m () > whileNotM t a = t >>= \b -> unless b $ a >> whileNotM t a > reader :: Handle -> IO () > reader h = whileNotM (hIsEOF h) (hGetLine h >>= putStrLn) The writer thread will write some lines to a handle and then close it. > writer :: Handle -> IO () > writer h = mapM_ (hPutStrLn h . replicate 10) ['a'..'z'] >> hClose h The main thread will do nothing, so far as can be observed, and exists solely to avoid premature termination of the program. > mainLoop :: IO () > mainLoop = forever $ threadDelay 1000000 Thanks for your attention, Claude -- http://claudiusmaximus.goto10.org

3 3