January 2010 - Haskell-Cafe

ANN: The Monad.Reader Issue 15
by Brent Yorgey 26 Jan '10

26 Jan '10

I am very pleased to announce that Issue 15 of The Monad.Reader is now available for your reading pleasure [1]. Issue 15 consists of the following four articles: * "The hp2any project" by Gergely Patai * "Adventures in Three Monads" by Edward Z. Yang * "The Operational Monad Tutorial" by Heinrich Apfelmus * "Implementing STM in pure Haskell" by Andrew Coppin Feel free to browse the source files. You can check out the entire repository using darcs: darcs get http://code.haskell.org/~byorgey/TMR/Issue15 If you'd like to write something for Issue 16, please get in touch. The deadline will likely be sometime in mid-late April; more details will be forthcoming. -Brent [1] http://themonadreader.files.wordpress.com/2010/01/issue15.pdf

2 1

HList darcs repo missing?
by Jake Wheat 26 Jan '10

26 Jan '10

Hello all, I was looking for the HList darcs repo at: http://darcs.haskell.org/HList/ but it seems to be missing. Has it been moved somewhere else? Thanks, Jake Wheat

4 4

list mail
by 田其雨 26 Jan '10

26 Jan '10

Sorry, for some reasons, I had to change my E-mail, so please don't send the list mail anymore, and I will get it with a new mail. Best wishes. _________________________________________________________________ Windows Live: Make it easier for your friends to see what you’re up to on Facebook. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/so…

1 0

scheduling an alarm
by Brian Denheyer 26 Jan '10

26 Jan '10

I cobbled the following together from bits and pieces I found on mailing lists. Seems straightforward, but the code I've included just sits there. The awaitSignal seems to be causing a problem, in that if I remove it (and don't call forever recursively) then I get my ALARM 5 sec later. Otherwise nothing. The problem is that if I don't include awaitSignal, then, of course, forever is called just as fast as the CPU will go :-) Brian import System.Posix.Signals import System.IO import Control.Concurrent alarm = do putStrLn "ALARM" hFlush stdout return () forever = do putStrLn "foo" scheduleAlarm 5 awaitSignal Nothing yield forever main = do installHandler realTimeAlarm (Catch alarm) Nothing forever

2 1

Codensity improvement of free monads
by Luke Palmer 25 Jan '10

25 Jan '10

Hello haskell-cafe, I have just read "Asymptotic Improvement of Computations over Free Monads" by Janis Voigtlander, since I have been working with free monads a lot recently and don't want to get hit by their quadratic performance when I start to care about that. But after reading the paper, I still don't really understand how "improve" actually improves anything. Can anyone provide a good explanation for where the work is saved? Luke

2 1

ANN: ftdi-0.1
by Roel van Dijk 25 Jan '10

25 Jan '10

Hello, I just released a very early version of my 'ftdi' library [1]. It is a small layer on top of the usb package [2] that enables you to communicate with FTDI [3] devices. Its design is based on the C-library libftdi [4], but it implemented completely in Haskell. Most functionality is untested. I only have access to an FT2232C chip, so testing other chips is not possible at the moment. Furthermore, the only thing I do with that chip is perform bulk reads and the occasional small (1 byte) bulk write. The good news is that it is quite good a bulk reads. It outperformed both libftdi-0.16 and the official driver [5] by about 40% for my use case. Although to be fair, both C libraries used the old libusb-0.1 library. This library is ultimately linked with libusb-1.0.* which is a complete rewrite. To play with the library either cabal install ftdi or darcs get http://code.haskell.org/~roelvandijk/code/ftdi Regards, Roel van Dijk 1 - http://hackage.haskell.org/package/ftdi 2 - http://ftdichip.com/ 3 - http://hackage.haskell.org/package/usb 4 - http://www.intra2net.com/en/developer/libftdi/ 5 - http://www.ftdichip.com/Drivers/D2XX.htm

1 0

Adopting hpodder?
by John Goerzen 25 Jan '10

25 Jan '10

Hi folks, I wrote hpodder a little while back. I no longer listen to podcasts at all (blame my Kindle for that). Is anyone here interested in adopting it and giving it some needed care? Thanks, -- John

1 0

Failing to install hxt
by haskell＠kudling.de 25 Jan '10

25 Jan '10

Hi guys, i have some troubles to install hxt. My first naive attempt "cabal install hxt" fails with "cabal: cannot configure hxt-8.5.0. It requires base >=4.2 && <5". I guess that's because i use ghc 6.10.4, since "base-4.2.0.0" depends on "integer-simple" which seems to only come with ghc 6.12. I then tried to install hxt-8.3.2, which seems to be the last version supporting ghc 6.10.4. If fails with: " src/Text/XML/HXT/Parser/TagSoup.hs:292:8: Not in scope: `optLookupEntity' cabal: Error: some packages failed to install: hxt-8.3.2 failed during the building phase. The exception was: exit: ExitFailure 1 " I have no idea, what that means. What am i doing wrong? Thanks, Lenny

5 13

Naive booleans and numbers - type-checking fails
by Dušan Kolář 25 Jan '10

25 Jan '10

Dear cafe, I'm trying to prepare a naive definition of booleans, numbers and some helper functions such a way, so that definition in lambda-calculus can be used in a straightforward way in Haskell. I was caught in trouble quite soon during change of lambda-expressions to Haskell - defining prefn as a helper for prev. When using Haskell-ish if-then-else then there is no problem (the code commented out), while using defined if-then-else (mif), the type-checking fails, but just for this case! Other simple tests are OK for the mif. Do I need some extra option for type-checker, or is it a principal failure (infinite type is reported) - I'm running ghci 6.10.4. > mtrue x y = x > mfalse x y = y > m0 f n = n > m1 f n = f n > m2 f n = f (f n) > msucc x g m = x g (g m) > iszero m = m (\_ -> mfalse) mtrue > mif c t f = c t f > mpair f s = \e -> e f s > mfst p = p mtrue > msnd p = p mfalse > -- mprefn f p = if mex True False then mth else mel > mprefn f p = mif mex mth mel > where > mex = mfst p > mth = mpair mfalse (msnd p) > mel = mpair mfalse (f (msnd p)) Please, change of definitions is not a solution, I'm trying to follow available resources, so using something else is not an option. :-( Thanks for any help Dusan

4 3

Re: [Haskell-cafe] Type level splices and instance deriving
by John Lato 25 Jan '10

25 Jan '10

Hello, > From: Khudyakov Alexey <alexey.skladnoy(a)gmail.com> > Hello > > However I run into problem with them. It's possible to create instance for > type class which doesn't have superclass. If it does have one compiler > complains that it could not deduce context. All my attempts to provide context > fail. What have you tried? > > Is that accidental limitation or because of Some Good Reason? Or just due to > lack of understanding on my side? > > Below is simplest example. >> {-# LANGUAGE FlexibleInstances #-} >> {-# LANGUAGE TemplateHaskell #-} >> import Language.Haskell.TH >> >> -- OK but require FlexibleInstances >> makeEq :: Name -> Q [Dec] >> makeEq name = >> [d| instance Eq $(conT name) where >> (==) = undefined >> |] >> >> -- Could not deduce Eq context >> makeOrd :: Name -> Q [Dec] >> makeOrd name = >> [d| instance Ord $(conT name) where >> compare = undefined >> |] > > And GHC output: > > test.hs:14:17: > Could not deduce (Eq t) from the context () > arising from the superclasses of an instance declaration > at test.hs:14:17-32 > Possible fix: add (Eq t) to the context of the instance declaration > In the instance declaration for `Ord t_aS5' > In the Template Haskell quotation > [d| > instance Ord $(conT name) where > { compare = undefined } |] > In the expression: > [d| > instance Ord $(conT name) where > { compare = undefined } |] I think this will work if you add the Eq constraint in the instance definition: makeOrd :: Name -> Q [Dec] makeOrd name = [d| instance Eq $(conT name) => Ord $(conT name) where compare = undefined |] The problem is that, when the (Ord t) instance is compiled, the compiler needs to know where to find the (Eq t) dictionary because Eq is a superclass of Ord. If 't' is a concrete type, e.g. Int, the compiler will look for the Eq instance and use it directly. If 't' is a type variable, as in your code, then the compiler needs to have the Eq constraint so that it can find the dictionary. In your case you provide an Eq instance for any type 't'. In theory I think the compiler could examine the instance, see that it's valid for any 't', and use that in your definition, but I don't think it's a good idea. This would be an extra branch that would only apply to a class that is instantiated for all types. Such an instance couldn't do anything useful; as an example your Eq instance is undefined. That's why GHC doesn't look for instances like the one you provided when determining type class constraints; they can't provide the necessary functionality. I suspect this feature could be added and then your code would compile, but you couldn't use it for anything so there's no point to doing so. Cheers, John

1 0