December 2010 - Haskell-Cafe

(Co/Contra)Functor and Comonad
by Mario Blažević 24 Dec '10

24 Dec '10

Why are Cofunctor and Comonad classes not a part of the base library? I recently defined a data type (Control.Cofunctor.Ticker in monad-coroutine on Hackage) that happens to be a co-functor, or contra-functor if you prefer. In other words, it can implement the following function: > cofmap :: (a -> b) -> cf b -> cf a I wanted to define a proper instance for it, but to my surprise I discovered that I couldn't. Not only is the class not defined in base, the only package I could find on Hackage that defines it is category-extras. This is a huge package I'd rather not have as a dependency, so I opted not to declare any instance. Later on I found that this question has been raised before by *Conal Elliott*, nearly four years ago. http://www.haskell.org/pipermail/libraries/2007-January/006740.html The result was the TypeCompose package, which presents a decent solution. I still can't think of any harm in having a proper class declaration in the base library: if you don't need it, you don't need to know it. But without the class declaration in the base library (or in some other obvious package) every other released library must either lack the instance declarations or declare the class itself and risk clashes. This is not some obscure class you've never encountered, by the way: any "consumer" of data is a cofunctor. All regexp data types, for example, are cofunctor instances - or would be if there was a class to declare them instances of. The same question extends to Comonad. I am not too familiar with this area so there may be fewer potential instances of the class, but I remember there was quite a bit of buzz around comonads a few years ago. Judging by a cursory Hayoo search, if anything the situation is worse than with Cofunctor: there are multiple incompatible declarations of the class scattered in various libraries that need it: ad, category-extras, data-category, rope. There is also evidence of undeclared Comonad instances: see the ListZipper and value-supply libraries. So, is it time to add these two classes to the base library?

9 13

Re: [Haskell-cafe] (Co/Contra)Functor and Comonad
by Mario Blažević 24 Dec '10

24 Dec '10

On Thu, Dec 23, 2010 at 11:25 PM, Tony Morris <tonymorris(a)gmail.com> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > ...regardless of the utility of a contravariant functor type-class, I > strongly advocate for calling it Contrafunctor and not Cofunctor. I > have seen numerous examples of confusion over this, particularly in > other languages. > I don't personally care what's it called, as long as it's available. Can anybody point to an authoritative source for the terminology, though? Wikipedia claims that cofunctor is a contravariant functor. Also, is there anything in category theory equivalent to the Functor -> Applicative -> Monad hierarchy , but with a Cofunctor/Contrafunctor at the base? I'm just curious, I'm not advocating adding the entire hierarchy to the base library. ;)

3 3

Cabal message problem.
by Magicloud Magiclouds 24 Dec '10

24 Dec '10

Hi, I see this kind of information a lot when I using cabal to install package. Or sometimes same packages both exist in global and user space, which is a "shadowed by" message. How to resolve that? Thanks. Resolving dependencies... <command line>: cannot satisfy -package Cabal-1.10.0.0: Cabal-1.10.0.0-9ac678c7f1e4f8dd31bac0e19f600698 is unusable due to missing or recursive dependencies: process-1.0.1.4-24e3819e5c17aaf49bfec6a0ab739420 (use -v for more information) -- 竹密岂妨流水过山高哪阻野云飞

8 18

GHC 7.0.1 developer challenges
by John D. Ramsdell 24 Dec '10

24 Dec '10

A quick review of GHC 7.0.1 revealed two challenges for developers. I downloaded the GHC 7.0.1 sources, configured for a home directory install, and built and installed the compiler. Very close to the end, my machine froze, perhaps due to memory exhaustion. In any event, a reboot allowed me to complete the installation. I tested the new compiler on an application I distribute, CPSA. The algorithm implemented by the program is not guaranteed to terminate, and it's hard to predict when non-termination is inevitable. Sometimes the way it terminates is to allocate all the memory in swap space and freeze the machine. It's an ugly crash. So in my documentation, I recommend people supply a runtime flag limiting memory usage. Due to a security concern, GHC 7.0.1 disables all runtime flags unless a new flag is provided during linking. Since limiting memory usage is so important, many developers will modify their cabal files to add the linker flag or prepare for complaints from users that the developer's program caused their machine to freeze and lose their work. The irony of this situation is deep. CPSA is a program that analyzes cryptographic protocols in an effort to expose security flaws. To ensure that the program does not crash a user's machine, I have to use a linker option that may expose the user to some security problems. There is one more disappointment in GHC 7.0.1 for developers. Cabal sdist is still hosed. Since ten months ago, cabal sdist fails to preserve the file mode bits of the source files put into the tarball being generated (Ticket #627 reported by draconx). An executable shell script and a source file world readable both have a mode of 600 in the tarball! So developers, continue to keep GHC 6.10.4 around so you can create source distributions. That's what I do. John

19 44

ANN: xmobar 0.12 released
by Jose A. Ortega Ruiz 23 Dec '10

23 Dec '10

I'm happy to announce a new relase of xmobar, the text-based monitor bar. You can read everything about xmobar and this release at our new web address (http://projects.haskell.org/xmobar/) or see below for a summary of what's new (cf. http://projects.haskell.org/xmobar/releases.html) ## Version 0.12 xmobar has a new [maintainer], a new [website], a new [mailing list] and uses a new [source code repository]. Many thanks to Andrea Rossato, xombar's author and maintainer so far, for creating xmobar in the first place, and for giving me the chance to become its maintainer. And a big thanks to Ben Boeckel, Petr Rockai and Norbert Zeh for their patches. [website]: http://projects.haskell.org/xmobar/ [mailing list]: http://projects.haskell.org/cgi-bin/mailman/listinfo/xmobar [source code repository]: https://github.com/jaor/xmobar [maintainer]: http://hacks-galore.org/jao/ _New features_ - Window borders: configuration options `border` and `borderColor` allow drawing borders around xmobar's window. - New monitor, `Uptime`, showing the system uptime. - New monitor argument (`-S`) to enable displaying the `%` symbol in percentages or other suffixes (e.g., units in Uptime and Network); the symbol is now never included by default. - New 'run once' commands, by specifying a 0 refresh rate in `Run Com` ([issue 26]). - MPD monitor: updated to libmpd 1.5. New fields `ppos` (playlist position) and `remaining` (remaining time). New configuration options to specify MPD's host, user name and password. - Battery monitor: new `watts` and `timeleft` fields (Petr Rockai), and specific arguments to control coloring and thresholds of the former. - MultiCPU monitor: new `auto*` fields that automatically detect all present CPUs (Ben Boeckel). - CpuFreq monitor uses just one decimal digit for GHz values (Petr Rockai). - Mail plugin expands paths starting with "~/" (Ben Boeckel). Ditto MBox. - Weather monitor now skips not retrieved fields, instead of displaying a long error message. - New compilation flag, `all_extensions`. - Documentation and website updates. _Bug fixes_ - [issue 23]: Wireless monitor is now compatible with iwlib 29. - [issue 24]: Swap monitor's used ratio display fixed. - [issue 25]: Percentages only include `%` if requested using `-P`. - [issue 31]: MPD monitor now respects `-W` argument. - Fixes in CPU frequency formatting, string alignment and colour boxes in monitors (Norbert Zeh). - TopMem and TopProc now use the `-L` and `-H` options correctly for memory template fields. - MBox skips non-existent mbox paths instead of hanging.

1 0

List of numbers to list of ranges
by C K Kashyap 23 Dec '10

23 Dec '10

Hi all, Here's my attempt to convert a list of integers to a list of range tuples - Given [1,2,3,6,8,9,10], I need [(1,3),(6,6),8,10)] My attempt using foldl yields me the output in reverse. I can ofcourse reverse the result, but what would be a better way? f xs = foldl ff [] xs where [] `ff` i = [(i,i)] ((s,e):ns) `ff` i = if i == e+1 then (s,i):ns else (i,i):(s,e):ns Regards, Kashyap

7 11

Do we need Monad fail (or MonadFail)?
by John Smith 23 Dec '10

23 Dec '10

Monads seem to use fail in one of three ways: -Regular monads leave it at the default definition of error -MonadPlus sometimes redefines it to mzero -IO redefines it to failIO Are there any other definitions of fail? If not, does the special case of IO really need a class-level definition, or could there be another way of dealing with failed pattern matches?

16 19

Why is Haskell flagging this?
by michael rice 23 Dec '10

23 Dec '10

I don't understand this error message. Haskell appears not to understand that 1 is a Num. Prelude> :t 1 1 :: (Num t) => t Prelude> :t [1,2,3,4,5] [1,2,3,4,5] :: (Num t) => [t] Prelude> Michael =================== f :: [Int] -> IO [Int] f lst = do return lst main = do let lst = f [1,2,3,4,5] fmap (+1) lst =============================== Prelude> :l test [1 of 1] Compiling Main ( test.hs, interpreted ) test.hs:5:17: No instance for (Num [Int]) arising from the literal `1' at test.hs:5:17 Possible fix: add an instance declaration for (Num [Int]) In the second argument of `(+)', namely `1' In the first argument of `fmap', namely `(+ 1)' In the expression: fmap (+ 1) lst Failed, modules loaded: none. Prelude>

14 24

Help!! Cannot get RandT and liftIO to work together...
by JP Moresmau 23 Dec '10

23 Dec '10

Hello all, sorry I must have taken my stupid pills this morning, I cannot get the following code to compile, what am I missing? data MyState=MyState Integer newState:: (RandomGen g) => RandT g IO MyState newState = do time<-liftIO getCPUTime rand<-getRandomR (1,6) return $ MyState (time+rand) newStateIO :: IO MyState newStateIO = do r<-getStdGen evalRandT newState r -> Could not deduce (MonadIO (RandT g IO)) from the context (RandomGen g) arising from a use of `liftIO' at ...:4:15-31 Possible fix: add (MonadIO (RandT g IO)) to the context of the type signature for `newState' or add an instance declaration for (MonadIO (RandT g IO)) Pirates.hs /Pirates/src line 167 Problem But the MonadRandom docs say: Instances: MonadIO<http://hackage.haskell.org/packages/archive/transformers/0.2.2.0/doc/html/C…> m => MonadIO<http://hackage.haskell.org/packages/archive/transformers/0.2.2.0/doc/html/C…> (RandT<http://hackage.haskell.org/packages/archive/MonadRandom/0.1.6/doc/html/Cont…> g m) And the MonadIO docs say: Instances: MonadIO<http://hackage.haskell.org/packages/archive/transformers/0.2.2.0/doc/html/C…> IO<http://hackage.haskell.org/packages/archive/base/4.3.1.0/doc/html/System-IO…> So it looks to me it should work! I've also tried to replace IO by MonadIO m=> in the signature, or remove all signatures. No joy. Thanks for any help. -- JP Moresmau http://jpmoresmau.blogspot.com/

2 5

Re: [Haskell-cafe] Functor => Applicative => Monad
by Simon Marlow 23 Dec '10

23 Dec '10

On 22/12/10 19:17, John Smith wrote: > On 22/12/2010 19:03, Simon Marlow wrote: >> On 14/12/2010 08:35, Isaac Dupree wrote: >>> On 12/14/10 03:13, John Smith wrote: >>>> I would like to formally propose that Monad become a subclass of >>>> Applicative, with a call for consensus by 1 February. The change is >>>> described on the wiki at >>>> http://haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal, >>> >>> That page isn't written as a proposal yet, it's written as a bunch of >>> ideas. I would be happy to see something along the lines of Bas van >>> Dijk's work >>> http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/14740 . >> >> This is a proposal with far-reaching consequences, and with several >> alternative designs. I'm not sure I understand all >> the tradeoffs. Some parts of the proposal are orthogonal to the rest >> (e.g. changing fmap to map), and should probably be >> considered separately. >> >> Could someone please write a detailed proposal, enumerating all the >> pros and cons, and the rationale for this design >> compared to other designs? >> >> Cheers, >> Simon > > The wiki page was admittedly too broad of scope when I first wrote it, > and it's getting broader with time. > > The ticket at http://hackage.haskell.org/trac/ghc/ticket/4834 has > patches for only one change, making Monad a subclass of Applicative. (I > would update the description to make this clear, but I can't edit the > ticket description, so this has been relegated to a comment.) Dealing with one issue at a time is great. But even with this single change, we need to weight up the advantages and disadvantages - it's difficult to make an assessment without trawling through long email threads, and yet I don't want to let the proposal pass without comment. So it would help a lot if someone could take the time to explain the design space and the tradeoffs. I know for example I have lots of code that defines a Monad instance and doesn't need an Applicative instance, so this change will force me to jump through hoops that I don't need to. Cheers, Simon

2 1