- Libraries - Haskell.org

Add everywhereM' to Data.Generics.Schemes
by Maciej Podgurski 25 Apr '10

25 Apr '10

Hello, as an analogue to everywhere', I suggest adding everywhereM' to Data.Generics.Schemes. The implementation would be everywhereM' :: Monad m => GenericM m -> GenericM m everywhereM' f x = do { x' <- f x; gmapM (everywhereM' f) x' } Best wishes, Maciej

4 4

Re: [Haskell-cafe] Announcement: Data.ISO3166_CountryCodes version 0.1
by John Millikin 24 Apr '10

24 Apr '10

Thanks for the library! I'm sure it will be very useful for people dealing with internationalized applications / libraries. I have a few suggestions, which might make your library easier to use and maintain. First, it's very common to include generated files in the tarball. This allows users to install the package, without installing 3rd-party utilities, or downloading (possibly varying) versions from external websites. As your library is currently written, two users who install it might end up with dramatically different modules, depending on the contents of < http://www.iso.org/iso/iso3166_en_code_lists.txt >. Second, since the module is based on an external data set, a date-based version might more appropriate. "Version 0.1" means nothing, but "version 2010.4.24" indicates when the given version was generated. Alternatively, you can use a hybrid system to indicate both stability and the date -- such as 0.1.20100424. Third, if you'd like your module to be widely used in the Haskell community, the BSD3 or MIT license would be more appropriate. For technical reasons, the GPL and LGPL are essentially equivalent for Haskell packages. For political reasons, choosing the GPL will reduce your user market to free-software users. This isn't *necessarily* bad -- all of my large projects are GPL'd -- but be aware that your choice will heavily limit how many people use your library. Fourth, consider storing your code in a version control system (like Darcs[1]), and publishing it on a website like Patch-Tag[2]. This enables people to contribute patches more easily. I've already checked it in as a branch[3] -- either branch mine, or create your own trunk. Finally, instead of using a Makefile to build the library or documentation, consider using the cabal-install utility[4]. It's much more common for a library to use "cabal build" or "cabal haddock" than custom make commands, and external tools (such as Hackage) will work better. Excepting the licensing change (which is your decision), all of these suggestions are implemented/published in my Darcs branch. If you opt to change the license, you may use any license you want for the code I've added / modified. [1] http://darcs.net/ [2] http://patch-tag.com/ [3] http://patch-tag.com/r/jmillikin/iso3166-country-codes/home [4] http://hackage.haskell.org/package/cabal-install On Sat, Apr 24, 2010 at 09:19, Jon Fairbairn <jon.fairbairn(a)cl.cam.ac.uk> wrote: > Just uploaded to hackage. > > Package providing datatype generated from the ISO3166 country code > list. > > This was originally part of my Typeful HTMLs stuff, but I > thought it deserved a wider audience. I think anything that uses > country codes should use this datatype! > > > As this is my first attempt at using cabal and uploading to > hackage, expect errors and omissions. > > In particular, as I didn't want it to depend on template > haskell, the build process generates the module's source file, > which means that that file shouldn't be in the tarball. Cabal > complains that it's missing if it's not there, so I created an > empty .hsc file to shut it up. I'm sure this is not the right > way, so I'd be glad to hear what is. > > -- > Jón Fairbairn Jon.Fairbairn(a)cl.cam.ac.uk > http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2009-01-31) > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

Move MonadIO to base
by Twan van Laarhoven 24 Apr '10

24 Apr '10

Hello, Some people have remarked that the MonadIO class would be better of in the base package instead of mtl/transformers. It can be used largely independently from the monad transformers, and it is useful without them. This has been previously discussed [1,2], but as far as I know nothing ever came of it. If MonadIO were in base, then the base library itself could also use it. For example the functions in System.IO could be lifted to work on any MonadIO monad. Whether that is a good idea is completely orthogonal to this discussion, however. How hard would it be to make this change? For backwards compatibility mtl and transformers would need a check to see which version of base is used, or new versions of mtl/transformers should just not include MonadIO. Twan [1] http://www.haskell.org/pipermail/libraries/2009-December/012914.html [2] http://hackage.haskell.org/trac/ghc/ticket/3777

15 36

Proposal #3999: Improved folds for Data.Map and Data.IntMap
by Louis Wasserman 24 Apr '10

24 Apr '10

http://hackage.haskell.org/trac/ghc/ticket/3999 Discussion deadline: May 7 Previously, Data.Map's Foldable instance consisted of instance Foldable (Map k) where foldMap ... Even though there were implementations for foldrWithKey and foldlWithKey, these weren't being used in the Foldable instance -- instead, the slower version derived from foldMap was in use. This is silly, since foldr and foldl can be easily derived from foldrWithKey and foldlWithKey. Additionally, it takes relatively little effort to ensure that keys, elems, toList, etc. deforest under folds. Therefore, we add the following rewrite rules: {-# RULES "foldr/Data.Map.elems" forall f z m . foldr f z (elems m) = foldr f z m; "foldl/Data.Map.elems" forall f z m . foldl f z (elems m) = foldl f z m; "foldr/Data.Map.keys" forall f z m . foldr f z (keys m) = foldrWithKey (\ k _ -> f k) z m; "foldl/Data.Map.keys" forall f z m . foldl f z (keys m) = foldlWithKey (\ z k _ -> f z k) z m; "foldr/Data.Map.toAscList" forall f z m . foldr f z (toAscList m) = foldrWithKey (curry f) z m; "foldl/Data.Map.toAscList" forall f z m . foldl f z (toAscList m) = foldlWithKey (curry . f) z m; #-} Finally, we implement foldrWithKey and foldlWithKey for Data.IntMap, and make the same adjustments to Data.IntMap as to Data.Map, adding specialized foldr and foldl definitions in the Foldable instance and adding the corresponding rewrite rules. The only API change is the addition of foldrWithKey and foldlWithKey to Data.IntMap, but folds over Maps and IntMaps are exposed to optimization. Louis Wasserman wasserman.louis(a)gmail.com http://profiles.google.com/wasserman.louis

4 8

Storable and constant memory
by Roman Leshchinskiy 23 Apr '10

23 Apr '10

Here is a problem that affects package vector, sometimes resulting in much slower code with Data.Vector.Storable (based on ForeignPtr and Storable) compared to Data.Vector.Unboxed (based on ByteArrays). Suppose we have a recursive function: foo :: Vector Int -> Maybe Int -> ... foo v x = ... foo v (Just (v ! i)) ... If v comes from Data.Vector.Unboxed, this eventually becomes: foo v x = ... foo v (Just (I# (indexIntArray# arr# i#))) ... Now SpecConstr kicks in, specialises foo for this particular call pattern and we get a nice unboxed loop: foo' :: Vector Int -> Int# -> ... foo' v n# = let x = Just (I# n#) in ... foo' v (indexIntArray# arr# i#) ... Alas, this doesn't work for Data.Vector.Storable. Here, we have to use peek which gives us this: foo v x = ... foo v (Just (case readIntOffAddr# p# i# realWorld# of { (# s#, n# #) -> case touch# fp s# of { _ -> I# n# }})) ... SpecConstr eliminates the Just but can't unbox the Int. With enough fiddling, it would be possible to implement collective operations such that they only touch# once at the end rather than after each element access. This significantly complicates stream fusion, however, and doesn't help with SpecConstr anyway since the stateful read still gets in the way. So the question is: would it perhaps be a good idea for Storable to include support for marshalling from constant memory? Also, can we do something about touch#? Perhaps it could have type (a -> b -> b) and then we could make SpecConstr look through it? Roman

2 4

Improving MonadIO
by Ben Franksen 22 Apr '10

22 Apr '10

There was once a very inspiring message from Jules Bean on the cafe, about "Monadic Tunneling" (http://www.haskell.org/pipermail/haskell-cafe/2007-July/028501.html) At the time his idea perfectly served my needs, so I wrote a module to encapsulate it. The code is below, maybe it adds another data point to the discussion about a better MonadIO. Note that the generality is not idle, I actually needed the transformer version in my project. (I have been thinking about uploading this to hackage as an independent module.) {-# LANGUAGE MultiParamTypeClasses, TypeFamilies, EmptyDataDecls #-} {-# LANGUAGE FlexibleInstances, FlexibleContexts, GeneralizedNewtypeDeriving #-} module Embed where import Control.Concurrent import Control.Exception import Control.Monad.Trans.Class import Control.Monad.Trans.Identity import Control.Monad.Trans.Reader import Prelude hiding (catch) -- * Class Embed class Embed i o where type Content i o embed :: (Content i o -> i a) -> o a callback :: o a -> Content i o -> i a liftE :: (Embed i o) => i a -> o a liftE action = embed (const action) -- If the inner monad is IO data Void -- | We would like to give an instance @Embed m m@ once and for all @m@. -- Unfortunately this does not play nicely with the generic instances below. instance Embed IO IO where type Content IO IO = Void embed f = f undefined callback action _ = action -- The constraint @Embed IO m@ is more powerful and useful than MonadIO, -- as it allows higher-ranked liftings. io :: (Embed IO m) => IO a -> m a io = liftE bracketE :: Embed IO m => m r -> (r -> m b) -> (r -> m a) -> m a bracketE before after during = embed $ \x -> bracket (before' x) (\a -> after' a x) (\a -> during' a x) where before' x = callback before x after' a x = callback (after a) x during' a x = callback (during a) x catchE :: (Embed IO m, Exception e) => m a -> (e -> m a) -> m a catchE action handler = embed $ \x -> catch (action' x) (\e -> handler' e x) where action' x = callback action x handler' e x = callback (handler e) x handleE :: (Embed IO m, Exception e) => (e -> m a) -> m a -> m a handleE = flip catchE throwE :: (Embed IO m, Exception e) => e -> m a throwE = liftE . throwIO forkE :: Embed IO m => m () -> m ThreadId forkE action = embed $ \x -> forkIO (callback action x) -- * Embedding Transformer class MonadTrans t => Embedding t where type ContentT t embedT :: (ContentT t -> m a) -> t m a callbackT :: t m a -> ContentT t -> m a defaultLift :: Embedding t => m a -> t m a defaultLift = embedT . const instance (Embed i o, Embedding t) => Embed i (t o) where type Content i (t o) = (ContentT t, Content i o) embed f = embedT (\x -> embed (\y -> f (x,y))) callback action (x,y) = callback (callbackT action x) y instance Embedding IdentityT where type ContentT IdentityT = Void embedT f = IdentityT (f undefined) callbackT action _ = runIdentityT action instance Embedding (ReaderT r) where type ContentT (ReaderT r) = r embedT = ReaderT callbackT = runReaderT

1 0

Re: Proposal #3999: Improved folds for Data.Map and Data.IntMap
by Louis Wasserman 22 Apr '10

22 Apr '10

Heh. Just to ask, though -- would anything major get broken if we *did* go ahead, modify base, and delay inlining foldl? Louis Wasserman wasserman.louis(a)gmail.com http://profiles.google.com/wasserman.louis On Thu, Apr 22, 2010 at 1:36 PM, Gwern Branwen <gwern0(a)gmail.com> wrote: > On Thu, Apr 22, 2010 at 12:15 PM, Roman Leshchinskiy <rl(a)cse.unsw.edu.au> > wrote: > > On 23/04/2010, at 00:32, Gwern Branwen wrote: > > > >> On Thu, Apr 22, 2010 at 4:08 AM, Roman Leshchinskiy <rl(a)cse.unsw.edu.au> > wrote: > >>> > >>> FWIW, I'm a bit surprised that you need foldl on lists anyway. I > thought everybody uses foldl'. > >> > >> Not nearly: > http://www.reddit.com/r/haskell/comments/bmd5u/thunks_and_haskell/c0nl7u2 > >> > >> There are a lot of foldl uses out there. > > > > Hmm, I'd love to see some real-world uses of foldl. I have no idea what > to optimise it for in vector. Unfortunately, the link above doesn't give any > examples. > > > > Roman > > Well, since you ask... > > $ find . -name "*.hs" -exec grep -H ' foldl ' {} \; > ~/fold.txt > $ wc ~/fold.txt > 2206 24333 225619 fold.txt > > -- > gwern >

1 0

cabal-install upgrade
by Ben Franksen 22 Apr '10

22 Apr '10

Hi Libraries ;-) I have ghc-6.10.4 and many libraries installed and everything works nicely. I'd like to upgrade my Cabal + cabal-install so I can use the new features (especially the improved support for library plus executables in one package). Is this safe? I mean, do I have to fear my installation breaks if I install Cabal-1.8.0.4? I have discovered problems when upgrading Cabal in the past but this is quite some time ago. Also, I am confused by the output of cabal-install regarding such an upgrade: ben@sarun[2]: ~ > cabal --version cabal-install version 0.6.4 using version 1.6.0.3 of the Cabal library ben@sarun[2]: ~ > cabal install cabal-install --dry-run Resolving dependencies... In order, the following would be installed (use -v for more details): cabal-install-0.6.4 ben@sarun[2]: ~ > cabal install Cabal --dry-run Resolving dependencies... In order, the following would be installed (use -v for more details): Cabal-1.8.0.4 ben@sarun[2]: ~ > cabal list cabal-install * cabal-install Synopsis: The command-line interface for Cabal and Hackage. Latest version available: 0.8.2 Latest version installed: [ Not installed ] Homepage: http://www.haskell.org/cabal/ License: BSD3 So, cabal-install would upgrade Cabal from 1.6.0.3 to 1.8.0.4, but not itself from 0.6.4 to 0.8.2. I used the -v option but it did not make clear to me which dependencies of 0.8.2 conflict with what I have installed. And maybe there is no conflict, since ben@sarun[2]: ~ > cabal install cabal-install-0.8.2 --dry-run Resolving dependencies... In order, the following would be installed (use -v for more details): Cabal-1.8.0.4 cabal-install-0.8.2 When I give cabal-install an explicit version number for the package to install, does this somehow circumvent safety measures? Thanks Ben

1 0

Re: [Haskell-cafe] Re: Move MonadIO to base
by wren ng thornton 21 Apr '10

21 Apr '10

wren ng thornton wrote: > Anders Kaseorg wrote: >> Yes; my question is more whether Wren has a more clever way to get an >> isomorphism (forall b. (m a -> IO b) -> IO b) <-> IO (m a) that would >> make the simpler interface work out. (Or maybe I misunderstood what >> he was getting at.) > > Yeah no, that's what I was getting at. Since it doesn't quite work > out, I should probably rethink my appeal to parametricity re Kleisli > arrows. No, my parametricity was correct, just the implementations were wrong: {-# LANGUAGE RankNTypes #-} module MorphIO where import Prelude hiding (catch) import Control.Monad import qualified Control.Exception as E import Control.Exception (NonTermination(..)) -- | The original class class Monad m => MonadMorphIO m where morphIO :: (forall b. (m a -> IO b) -> IO b) -> m a -- | The isomorphic Haskell98 version class Monad m => MonadJoinIO m where -- | Embed the IO into the monad m joinIO :: IO (m a) -> m a -- | Extract the IO computation to the top level, -- rendering the m pure from IO. partIO :: m a -> IO (m a) -- | The isomorphisms joinIO' m = morphIO (m >>=) morphIO' f = joinIO (f partIO) -- * Example instance MonadMorphIO IO where morphIO f = f id instance MonadJoinIO IO where joinIO = join partIO = fmap return -- N.B. fmap return /= return catch m h = morphIO $ \w -> w m `E.catch` \e -> w (h e) catch' m h = morphIO' $ \w -> w m `E.catch` \e -> w (h e) test = E.throwIO NonTermination `catch` \NonTermination -> return "moo" test' = E.throwIO NonTermination `catch'` \NonTermination -> return "moo" -- Live well, ~wren

3 2

Re: Generalize MonadIO to MonadBase
by John Lato 21 Apr '10

21 Apr '10

> From: Bas van Dijk <v.dijk.bas(a)gmail.com> > > Hello, > > (This should actually be a reply to the "Move MonadIO to base" > thread[1] but I didn't want to break up the extremely interesting > discussion on the MonadTransMorph class) > > Would it be useful if we got rid of MonadIO: > > class (Monad m) => MonadIO m where liftIO :: IO a -> m a > > and replace it with the generalization: > > class (Monad m, Monad n) => MonadBase m n | m -> n where inBase :: n a -> m a > > which would allow lifting not just IO but any base monad into a stack > of monad transformers. > I personally wouldn't find this particularly useful. Nearly all of my monadic programming (i.e. everything that comes to mind) uses one of three types of monads: 1. IO 2. ST 3. Monad transformers stacked on IO Lifting functions are only useful in the third case, and then I only need "lift" and "liftIO". I do like the idea and I'm not opposed to the suggestion, I just don't see a use for it myself. John

6 6