- Libraries - Haskell.org

Re: different flavours of Monad Transformer Library (fwd)
by Mauro J. Jaskelioff 12 Jan '09

12 Jan '09

Hi, sorry for the late reply, I have no problem with your proposal (mtl-data). I'd prefer to have all the liftings in the same package, though (and not just separate the ones with FD). I also like Ross' idea of monads being synonyms for transformers at Id. It removes lots of repeated code. Wrt portability, I'm working an another experimental monad transformer library (http://www.cs.nott.ac.uk/~mjj/monatron ) which, unlike mmtl, does not try to be backwards compatible with mtl. It contains a core with full functionality (except operation overloading) which should work in Haskell 98+Rank2Functors. Lack of operation overloading means you have to be explicit about the liftings. (for example, declare you want the operation 'catch' lifted through 2 monad transformers) With other extensions (FD, multiparameter classes, etc.) you also get operation overloading. All the best, - Mauro Henning Thielemann wrote: > > I don't know whether you are on the libraries(a)haskell.org list ... > > ---------- Forwarded message ---------- > Date: Sun, 4 Jan 2009 23:50:28 +0000 > From: Ross Paterson <ross(a)soi.city.ac.uk> > To: libraries(a)haskell.org > Subject: Re: different flavours of Monad Template Library > > On Sun, Jan 04, 2009 at 11:22:15PM +0100, Henning Thielemann wrote: >> I see now at least three MTL libraries at hackage, namely >> mtl >> mmtl >> mtl-tf >> >> They all define both the example data types and according type classes >> in modules with the same name. This way you can only use one of these >> packages in all packages you import. However the data types are defined >> the same way in the packages, only the classes differ. >> >> I wished, there would be one package defining only the datatypes, say >> "mtl-data", and three ones with the names "mtl", "mmtl", "mtl-tf" that >> define their classes with corresponding instances. These classes should >> be in different modules, so you can use different class frameworks in >> the >> same project. The data type package would be useful on its own and could >> be run on the simplest Haskell compilers, since no functional >> dependencies are required. > > I agree. I had a go at such a restructuring of mtl a while ago: > > http://darcs.haskell.org/packages/transformers/ > http://darcs.haskell.org/packages/mtl-split/ > > The first is a Haskell 98 package that defines the monad transformers, > operations and liftings, like the mtl-data suggestion. The second adds > the FD-based classes. It's close to complete compatibility with mtl, > except that State is a synonym for StateT Identity etc. The main > problem was haddock's limitations with inter-package re-exports. > >> However there is the compatibility problem: Currently >> Control.Monad.State exports also the MonadState class, which would no >> longer work. Maybe we can reserve Control.Monad.State for mtl, which >> exports Control.Monad.State.Data.Lazy from mtl-data and >> Control.Monad.State.Class from mtl. > > I used Control.Monad.Trans.State.Lazy for the transformer. > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

4 3

MonadPlus instance for ContT
by Wolfgang Jeltsch 12 Jan '09

12 Jan '09

Hello, I wonder why there isn’t a MonadPlus instance for ContT. In my opinion, this one would be natural: > instance (MonadPlus monad) => MonadPlus (ContT result monad) where > > mzero = ContT $ return mzero > > ContT cont1 `mplus` ContT cont2 = ContT $ liftM2 mplus cont1 cont2 return and liftM2 are the ones of (->) (o -> monad result). What do you think? Best wishes, Wolfgang

2 2

Announcing Haskell protocol-buffers 1.4.0 (the smashing recursive edition)
by Chris Kuklewicz 09 Jan '09

09 Jan '09

Hello, What is protocol-buffers? Google's "..language-neutral, platform-neutral, extensible way of serializing structured data for use in communications protocols, data storage, and more." http://code.google.com/apis/protocolbuffers/docs/overview.html What is Haskell protocol-buffers? This provides a program 'hprotoc' which compiles a ".proto" file defining messages to Haskell modules, and the protocol-buffers API to access them and convert back and forth to the binary wire protocol, and protocol-buffers-descriptors which are messages which describe ".proto" files and allow for runtime reflection of annotated message definitions. The big addition to this version (which is 1.4.0) over the previous version (which was 1.2.0) is for when modules are in a dependency loop. The most common reason this happens is whenever a message is extended in the same proto file but outside of the message itself (e.g. at the top level). This was salved in previous versions by telling the user to create boilerplate header files (a .hs-boot file) and add a few {-# SOURCE #-} pragmas. This was primitive, and could not cover all the corner cases. Those days are gone. The new version of hprotoc uses the cutting edge version of haskell-src-exts (4.8.0) to generate not only the Haskell modules but also the hs-boot files and {-# SOURCE #-} pragmas! This is truly a glorious way to start the New Year. But wait, there is more! If a more than two messages define extensions of each other in a strongly connected dependency graph then the hs-boot files are not enough. For these strange cases hprotoc will now generate modules ending with 'Key.hs that separately define the extensions. You do not need to lift a finger, you never need to import these modules yourself, this all exists behind the scenes. Also, hprotoc goes way out its way to reduce the number of .hs-boot and 'Key.hs files, and it uses only a minimal set of {-# SOURCE #-} pragmas. It is so painless that if I did not put this into this announcement you might not even know. Now all generated should compile with no changes or additions. Of course, hprotoc still generates nothing for services and methods. Where to get the new shiny packages? hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/protocol-buffers http://hackage.haskell.org/cgi-bin/hackage-scripts/package/protocol-buffers… http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hprotoc And you will need haskell-src-exts, version 0.4.8, by Niklas Broberg: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts… (past version do not work and future versions will probably change enough to break compilation of hprotoc) Happy New Year, Chris Kuklewicz

1 0

Re: Bug in network library, uncaught exception when dealing with ipv6 sockets
by Thomas Hartman 08 Jan '09

08 Jan '09

ok. http://hackage.haskell.org/trac/ghc/ticket/2927 2009/1/8 Thomas Hartman <tphyahoo(a)gmail.com>: > ok. > > http://hackage.haskell.org/trac/ghc/ticket/2927 > > 2009/1/8 Don Stewart <dons(a)galois.com>: >> tphyahoo: >>> >>> There is an uncaught exception in the network library which is causing >>> my HAppS demo website >>> >>> http://happstutorial.com >> >> If it is the Haskell network library, could you submit a patch there? >> >> -- Don >> >

1 0

Bug in network library, uncaught exception when dealing with ipv6 sockets
by Thomas Hartman 08 Jan '09

08 Jan '09

There is an uncaught exception in the network library which is causing my HAppS demo website http://happstutorial.com to crash every couple of days. This has affected other people using HAppS as well, as described on postings to the HAppS users list. The bug, and workarounds, is described at http://code.google.com/p/happs/issues/detail?id=40 This message is to suggest a fix for the issue. The problem seems to me to be localized in the following bit of code, from -- http://hackage.haskell.org/packages/archive/network/2.2.0.1/doc/html/src/Ne… *************************** #if defined(IPV6_SOCKET_SUPPORT) accept sock@(MkSocket _ AF_INET6 _ _ _) = do (sock', addr) <- Socket.accept sock (Just peer, _) <- getNameInfo [] True False addr handle <- socketToHandle sock' ReadWriteMode (PortNumber port) <- socketPort sock' return (handle, peer, port) #endif *************************** The problem is that getNameInfo can give rise to an IO exception, which should be caught at the library level. An exception IS caught at the library level when fetching peer for ipv4 packets, as follows. Since the code can never crash when fetching peer for ipv4 packets, it seems to me it shouldn't be allowed to crash when fetching peer for ipv6 packets either. ip v4 packet code: *************************** accept sock@(MkSocket _ AF_INET _ _ _) = do ~(sock', (SockAddrInet port haddr)) <- Socket.accept sock peer <- catchIO (do (HostEntry peer _ _ _) <- getHostByAddr AF_INET haddr return peer ) (\e -> inet_ntoa haddr) -- if getHostByName fails, we fall back to the IP address handle <- socketToHandle sock' ReadWriteMode return (handle, peer, port) *************************** My suggestion for fixing for ipv6 is as follows, basically having similar error catching as for ipv4. *************************** #if defined(IPV6_SOCKET_SUPPORT) accept sock@(MkSocket _ AF_INET6 _ _ _) = do (sock', addr@((SockAddrInet port haddr) )) <- Socket.accept sock (Just peer, _) <- catchIO ( getNameInfo [] True False addr ) (\e -> do peerAsIp <- inet_ntoa haddr return (Just peerAsIp, undefined)) handle <- socketToHandle sock' ReadWriteMode (PortNumber port) <- socketPort sock' return (handle, peer, port) #endif *************************** Des this seem reasonable? Of course, please advise if I should repost this issue to the ghc bugtracker, or similar. Thanks also to Matt Elder for being very generous with his time in helping me diagnose this. And also thanks to the others on the above-linked HAppS bug thread. Thomas.

2 2

cabal usage
by Johannes Waldmann 08 Jan '09

08 Jan '09

what is the recommended way (fewest keystrokes) for: * cabal install foo (download from hackage) * build failure => edit sources => repeat install on modified sources Is it really "cabal fetch foo" then "tar xvfz ~/.cabal/some/very/long/pathname.tgz" ? during the original "cabal install", sources seem to be in /tmp/TMPfoo-*/* but they are removed on failure. or - is this a workflow that should not happen (e.g. it might lead to confusing error messages later because "ghc-pkg list" shows the original version number if I forget to bump it while patching the sources) J.W.

2 1

hsql[-mysql]
by Johannes Waldmann 08 Jan '09

08 Jan '09

can we fix the situation with hsql[-mysql]? it seems there are three versions, all named "-1.7", and none of them working with recent ghc: * http://htoolkit.sourceforge.net/ original project site * http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hsql (build failures with ghc-6.8, 6.10) * http://code.haskell.org/HSQL/ current maintainer's site (build failures with 6.10) Since I needed this, I adapted the *.cabal and Setup.hs so they work with ghc-6.8 and 6.10. Since I posted this remark http://article.gmane.org/gmane.comp.lang.haskell.libraries/10299 I got several requests for these. So I'm making them available here provisionally (named *-1.7.1): http://dfa.imn.htwk-leipzig.de/~waldmann/draft/HSQL/ ... but of course this only adds to the confusion. best regards, J.W.

1 0

Proposal #2560 again: add newtype Down/ReverseOrd to Data.Ord
by Twan van Laarhoven 07 Jan '09

07 Jan '09

Hello list, About two and a half months ago I proposed that the following newtype (under the name "Down") be added to Data.Ord: newtype ReverseOrd a = ReverseOrd { getReverseOrd :: a } instance Ord ReverseOrd where a <= b = getReverseOrd b <= getReverseOrd a -- other methods, etc. I never followed up to that post, so I am doing that now. Since the discussion period has ended, let me summarize of responses: 1. Everyone is in favor of adding it 2. There is some criticism of the name 3. Some people (apfelmus) didn't like the getReverseOrd function As an alternative name, Isaac suggested "Reverse", "ReverseOrd" or "Opposite". I don't really like the name "Reverse", because that can mean many things: reversing a list, reverse order of composition, inverse/reverse a relation, etc. Although it is a bit verbose, "ReverseOrd" is the most clear. Concerning the "get" function: there is lots precedence in - Monoid wrappers (Sum, Product, Endo, etc.) - Applicative wrappers (ZipList, Const, etc.) - mtl types (State, Reader, etc.), To resolve the naming bikeshed issue, and because it has been a long time since the discussion ended, I propose an additional discussion period of 1 week, ending January 13. Twan

10 14

time package in the GHC build
by Ashley Yakeley 04 Jan '09

04 Jan '09

Can I remove the time package from the GHC build process? I want to update it but I don't want to deal with GHC's autotools stuff or break the GHC build. -- Ashley Yakeley

2 1

Endo-Monoid of lists = differences lists
by Henning Thielemann 02 Jan '09

02 Jan '09

How about a function for the Endo monoid, that lifts from a single value. toEndo :: (Monoid a) => a -> Endo a toEndo x = Endo (mappend x) For 'a' being a list type one would have a nice difference list. This may also occur in the documentation - both in the ones of Monoid.Endo and the of http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dlist . A similar application is Peano number with efficient addition. Would also be a nice type for ShowS.

1 0