- Libraries - Haskell.org

Crypto Package Ownership
by Dominic Steinitz 15 Feb '09

15 Feb '09

Creighton Hogg has very kindly volunteered to take over its maintenance. The code base is kept on code.haskell.org: > dom@nun:/srv/code/crypto$ ls -ltr > total 92 > -rw-rw-r-- 1 dom crypto-p 6711 Dec 6 09:29 SymmetricTest.hs > -rw-rw-r-- 1 dom crypto-p 79 Dec 6 09:29 Setup.hs > -rw-rw-r-- 1 dom crypto-p 8779 Dec 6 09:29 SHA1Test.hs > -rw-rw-r-- 1 dom crypto-p 4910 Dec 6 09:29 RSATest.hs > -rw-rw-r-- 1 dom crypto-p 2245 Dec 6 09:29 QuickTest.hs > -rw-rw-r-- 1 dom crypto-p 4918 Dec 6 09:29 HMACTest.hs > drwxrwsr-x 3 dom crypto-p 4096 Dec 6 09:29 Data > -rw-rw-r-- 1 dom crypto-p 1975 Dec 6 09:29 CryptoHomePage.html~ > drwxrwsr-x 5 dom crypto-p 4096 Dec 6 09:35 oldrepo > drwxrwsr-x 2 dom crypto-p 4096 Jan 4 03:56 doc > -rw-rw-r-- 1 dom crypto-p 2534 Jan 4 03:56 WordListTest.hs > drwxrwsr-x 5 dom crypto-p 4096 Jan 4 03:56 Codec > -rw-rw-r-- 1 dom crypto-p 3644 Jan 4 03:58 crypto.cabal > -rw-rw-r-- 1 dom crypto-p 10839 Jan 4 03:58 ReadMe.tex > drwxrwsr-x 6 dom crypto-p 4096 Jan 4 03:58 _darcs > -rw-rw-r-- 1 dom crypto-p 1973 Jan 4 04:01 CryptoHomePage.html Is there a way of changing the owner? Creighton's account is wchogg. Many thanks, Dominic.

2 2

Control.Concurrent.MVar documentation broken
by David Menendez 13 Feb '09

13 Feb '09

I was just looking at <http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurre…> and I noticed that the documentation for withMVar, modifyMVar, and modifyMVar_ is missing. This appears to be caused by the INLINE pragmas. I've done some experiments, and I've found that Haddock 2.4.1 will not display the documentation if an INLINE, NOINLINE, or SPECIALIZE pragma appears between the documentation and the signature. I don't know whether this is a bug in Haddock or Control.Concurrent.MVar. -- Dave Menendez <dave(a)zednenem.com> <http://www.eyrie.org/~zednenem/>

2 1

Binary: Put -> Builder
by Henning Thielemann 13 Feb '09

13 Feb '09

Is there a way to get the underlying Builder of a 'put' of a Binary instance? How does the Char instance of Binary serialize?

7 14

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