August 2009 - Haskell-Cafe

Arrows extentions and ArrowApplicable
by Maciej Piechotka 28 Aug '09

28 Aug '09

Arrows syntax supports Arrow, ArrowChoice(if, case etc.) and ArrowLoop(rec) - but not ArrowApplicable. Therefore it is not possible to write: proc x -> do a <- someArrow -< x a -< x but proc x -> do a <- someArrow -< x app -< (a, x) and proc x -> do a <- someArrow -< x app -< (otherArrow a, x) instead of proc x -> do a <- someArrow -< x otherArrow a -< x Such approach adds some syntax sugar but without adding any additional keyword and IMHO it can simplify writing ArrowApply (especially Kleisli IO). Regards

2 1

Mapping over multiple values of a list at once?
by haskell＠kudling.de 28 Aug '09

28 Aug '09

Hi, Imagine you have a list with n-values. You are asked to iterate over the list and calculate the average value of each 3 neighbouring values. For example, starting from [4,3,2,6,7] you need to find the averages of 4,3,2 and 3,2,6 and 2,6,7 resulting in [3,4,5] What is the most elegant way to do that? The naive ansatz to use "(!!") excessively sounds pretty inefficient. Bye, Lenny

8 8

Uninstall a cabal package?
by Colin Paul Adams 28 Aug '09

28 Aug '09

What is the procedure to uninstall a cabal package? -- Colin Adams Preston Lancashire

2 2

tomorrow: Edinburgh Meetup (Sat 29 Aug) and Hack Day (Sun 30 Aug)
by Eric Y. Kow 28 Aug '09

28 Aug '09

Dear Haskellers, Last minute reminder: We will be having a Hack Day in Edinburgh on Sunday 30 August (ICFP venue). That's this weekend! For the interested, we will also be meeting up the day before 09:30 Saturday 29 August just outside the RCPE (ie. the ICFP venue again). We'll have a quick wander and hopefully find some nice places to sit, chat and hack. On Sunday the real Hack Day begins at the ICFP venue, rooms 4/5. http://www.haskell.org/haskellwiki/Hac7 And for the interested, Brent says: > I'll be there Saturday morning---looking forward to meeting people! > > Also, I have purchased a ticket to hear a concert of some 16th-century > a capella 16th-century music at the Canongate Kirk at 5pm on Saturday: > > http://www.edfringe.com/ticketing/detail.php?id=13649 > > Just thought I'd mention it, so if there's anyone else coming to the > meetup day and 16th-century a capella sounds like your cup of tea, you > can get a ticket too and we can go together. Looking forward to seeing you, Eric PS. Bring a name tag if you've got one. There are about 15 people registered so far. It's not too late to register! (yes, you could also just drop by...) -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9

1 0

Applicative and Monad transformers
by Jeremy Shaw 28 Aug '09

28 Aug '09

Hello, I have seen it said that all Monads are Applicative Functors because you can just do: instance (Monad f, Applicative f) => Applicative (ReaderT r f) where pure = return (<*>) = ap However, that instance for ReaderT does not exhibit the properties I was hoping for. By substitution the definition of ap: ap :: (Monad m) => m (a -> b) -> m a -> m b ap = liftM2 id liftM2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r liftM2 f m1 m2 = do { x1 <- m1; x2 <- m2; return (f x1 x2) } we see that it becomes: instance (Monad f, Applicative f) => Applicative (ReaderT r f) where pure = return f <*> x = do { f' <- f; x' <- x; return (f' x') } What I would prefer is: instance (Monad f, Applicative f) => Applicative (ReaderT r f) where pure a = ReaderT $ const (pure a) f <*> a = ReaderT $ \r -> ((runReaderT f r) <*> (runReaderT a r)) I assume that only one version is correct, but I am having a hard time figuring out which one. I have attached a file which shows my motivation for prefering the second variation. There is a 'looker' function which does three lookups and combines the results using the Applicative Functor. With the first Applicative instance for ReaderT you will only get a failure message for the first lookup that fails -- which is what you expect with monadic behaviour. With the second instance, you get back a list of all the lookups that failed, which seems like what I would expect with Applicative Functor behaviour. Thanks! - jeremy {-# LANGUAGE FlexibleContexts, FlexibleInstances #-} module Main where import Control.Applicative (Applicative((<*>), pure), (<$>)) import Control.Monad (Monad((>>=), return), ap) import Control.Monad.Reader (MonadReader(ask, local), ReaderT(ReaderT, runReaderT)) import Data.Monoid(Monoid(mappend)) instance (Monad f, Applicative f) => Applicative (ReaderT r f) where pure = return (<*>) = ap {- instance (Monad f, Applicative f) => Applicative (ReaderT r f) where pure a = ReaderT $ const (pure a) f <*> a = ReaderT $ \r -> ((runReaderT f r) <*> (runReaderT a r)) -} instance (Monoid e) => Applicative (Either e) where pure = Right (Left errF) <*> (Left errA) = Left (errF `mappend` errA) (Left err) <*> _ = Left err _ <*> (Left err) = Left err (Right f) <*> (Right a) = Right (f a) instance Monad (Either [String]) where return = Right (Right a) >>= f = f a (Left e) >>= f = (Left e) fail str = Left [str] lookupE :: (Eq a) => a -> [(a,b)] -> (Either a b) lookupE a env = case lookup a env of Just b -> Right b Nothing -> Left a look :: String -> ReaderT [(String,b)] (Either [String]) b look a = do env <- ask case lookup a env of Just b -> return b Nothing -> fail a looker :: ReaderT [(String, Int)] (Either [String]) (Int, Int, Int) looker = ((,,) <$> look "foo" <*> look "bar" <*> look "baz") test :: Either [String] (Int, Int, Int) test = runReaderT looker [("bar", 1)]

6 8

ANNOUNCE: jhc 0.7.1
by John Meacham 27 Aug '09

27 Aug '09

Hi, I am happy to announce the jhc optimizing haskell compiler version 0.7.1. Information on installing jhc is here: http://repetae.net/computer/jhc/building.shtml And the Main page is here: http://repetae.net/computer/jhc There have been a lot of changes since the last public release, Some notable ones are: * The use of a general compiler cache by default rather than object files. This means work done by jhc is shared between projects, jhc uses cryptographic hashes internally to never compile the same piece of code more than once. This has numerous benefits, a notable one being speed. * Reworked library support. Jhc libraries are now much more general, when linking only the bits needed are loaded from the hl file, libraries are allowed to re-export modules from other libraries, making versioning or providing multiple interfaces to the same functionality a lot simpler. Library conflicts are 'lazy', like ambiguity errors now. * Updated Manual, clearer build instructions * Support for writing pure C libraries in Haskell. * numerous library updates, filled out many IO routines that were stubs before * Smart progress meters when compiler for a better user experience * performs all typechecking before compilation, for a faster edit-compile loop when writing code with jhc. * various bug fixes * Cross Compilation improvements, for instance you can compile for windows transparently on a linux box. Or for an embedded target that is independent of the host. * Better Mac OSX Support, as both a host and target. If you are wondering about the large version number bump since the last release, It is because several versions were released only internally to the jhc list for testing. If you are interested in jhc, join the list at: http://www.haskell.org/mailman/listinfo/jhc John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/

5 5

Killing a thread blocking on a foreign call
by John Van Enk 27 Aug '09

27 Aug '09

Hi List, I'm trying to kill a thread (during program cleanup) that is almost always going to be perma-blocking on a foreign call (read). It seems that there's no facility to do this built into Haskell at this point, or is there? /jve

1 0

Inexplicable allocation
by Rohan Lean 27 Aug '09

27 Aug '09

Hello, this is my first posting to this List, I hope everything goes well. Seeing that the haskell is currently poorly represented in the fasta benchmark at http://shootout.alioth.debian.org/u64q/benchmark.php?test=fasta&lang=all , I decided to help out the contributors a bit. My draft already performs considerably better than the current program, but while optimizing I ran into a weird problem. I already reported this as a ghc bug, but on IRC I was encouraged to also describe my problem here. Source of the program: http://rohanlean.de/pub/ghc_alloc/fasta.hs Core: http://rohanlean.de/pub/ghc_alloc/fasta.core Relevant port of the core (`gen' with inlined `pick'): http://rohanlean.de/pub/ghc_alloc/fasta_snip.core Running with the -p option suggested that `gen' and `pick' allocate a lot of memory throughout the run of the program (that memory is not retained). I managed to confirm that for non-profiling builds by observing how the the output of -sstderr changed when I modified `gen' to call itself fewer times. This came as a surprise, because expected these two functions to be completely allocation free, and the core does not suggest any allocation to me. I would very much welcome explanations for these reported allocations. Thank you, Rohan Lean

1 0

Re: [Haskell-cafe] ANN: scion 0.1
by Thomas Schilling 27 Aug '09

27 Aug '09

On 27 Aug 2009, at 09:17, Johan Tibell wrote: > Hi Thomas, > > This is really cool stuff. I played with it this morning and found a > potential bug. Both the emacs and vim client libraries refer to the > binary "scion_server" but the binary that gets built and put in > ~/.cabal/bin is called "scion-server" (note the dash). I worked around > the problem by putting this in my .emacs: Right, I changed that before the release and apparently forgot to change a few places. Will be fixed in the next minor version. > > (setq scion-program "scion-server") > > Also, I tried to play with the scion-open-cabal-project function. I'm > not sure I understand how it's intended to be used. Does it make sure > that if you compile a file using C-c C-x C-l the right source > directories are used? Could you give a usage example? I eventually want to get rid of it and let scion-load figure out itself when the project needs to be reconfigured. At the moment you have to delete the .dist-scion directory if you changed your .cabal file. :/ > > One problem I frequently have with emacs-mode is that you can't use it > to load a file if > > * your sources don't live in the same directory as the Cabal file, or Actually, the latest version of haskell-mode has some heuristics. It sets the working directory to where the .cabal file lives. > * the file needs preprocessing (e.g. it's a .hsc) file. > > Now when we have the Cabal file loaded would it be possible to have > Cabal compile the project and then try to load the .hs file generated > from the .hsc file that is currently opened? Right, so those files should be generated, but it's quite difficult to update them automatically and recompile the necessary files. Also, some preprocessers don't add the proper {-# LINE #-} markers, so the error messages will be all wrong. So, I think it should work this way: User opens a .hsc / .y / .x file, Scion figures out that the file needs preprocessing, loads the generated file and highlights the error messages and highlights them in the original file. > > Thanks! > > -- Johan / Thomas -- Push the envelope. Watch it bend.

2 1

Qualified operators
by Colin Paul Adams 27 Aug '09

27 Aug '09

What's the syntax for using a qualified operator (I have a clash of !)? -- Colin Adams Preston Lancashire

2 2