March 2014 - Haskell-Cafe

Feedback/Ideas for a Master Thesis about creating a Querying Tool for Hackage
by Victor Nithander 13 Apr '14

13 Apr '14

Hi, My name is Victor Nithander and I am currently doing my Master Thesis at the Computer Science and Engineering department at Chalmers in Gothenburg and would like to ask you for some help. My Master Thesis is about creating a querying tool for Hackage written in Haskell and I would like to know what kind of features you would like the querying tool to have. My plan is to design and implement an embedded language for queries to be expressed in and then implement a backend which accordingly takes care of those queries. I then plan to packet the tool as a package using Cabal and upload it to Hackage. Any feedback/ideas on features or other things about the tool would be greatly appreciated as I want to make a tool which benefits the community as much as possible. Examples of queries I'm thinking of to implement is: - Which language features (such as typeclass instances) does a certain package use? - How many packages uses a certain language feature? - Which packages does a certain package depend on? - Which packages depends on a certain package? Of course, this in no way limits what other type of queries could be made. I will also post this at the Haskell Section of reddit at http://www.reddit.com/r/haskell/, sorry for the redundancy. Feel free to respond to this either at this mailing list, at reddit, or as a personal email at nithande(a)student.chalmers.se though I think the best would be to have an open discussion about it. Thanks in advance! / Victor

3 2

Towards a better time library (announcing tz)
by Mihaly Barasz 08 Apr '14

08 Apr '14

I would like to propose reforming the 'time' [1] library. Initially, I was just planning to announce my new 'tz' [2] library, but realized that I have a more important agenda. Namely: Haskell needs a better time library! Let me summarize what are ‒ in my view ‒ the biggest deficiencies of 'time': 1. Inefficient data structures and implementations. 2. Ad-hoc API which is hard to remember and frustrating to work with. 3. Conceptually wrong representations and/or missing concepts. The wonderful thyme [3] package (by Liyang HU) improves a lot on #1 by choosing better data structures and careful implementations and on #2 by lensifying the API. But, it was the #3 that caused me the most frustration lately; most importantly the time zone handling. There is a TimeZone data type in 'time', but it is a misnomer, it basically represents a fixed time difference (with a label and a DST flag). 'time' basically adapts the broken approach from libc: you can work with one time zone at a time, which is defined globally for your program (via the TZ environment variable). So, the transformation between UTCTime and LocalTime which should have been a pure function can only be done in IO now. Like this: do tz <- getTimeZone ut return $ utcToLocalTime tz ut Oh, and just to hammer down on the point #1 from the list above. This code runs in about 6100 ns on my machine. The drop-in replacement from tz: utcToLocalTimeTZ [4] (which is actually pure) runs in 2300 ns. While this is a significant improvement, it's easy to miss the point where the bulk of the inefficiency comes from the data structures. In my main project we represent times as Int64 (raw nanoseconds since UNIX epoch; and similar representation for zoned times). And to convert those to and from different time zones we need 40 ns. That's right, a 150 _times_ improvement! (There are many other interesting benchmark results that I could mention. An exciting bottom line: we can actually beat the libc in many use-cases!) The 'tz' package is still very much in flux. I will try to solidify the API soon, but until then it should be considered more of a proof of concept. There is some missing functionality, for example. On the other hand, there are the 'timezone-series' [5] and 'timezone-olson' [6] packages that together provide about the same functionality as 'tz' (minus the efficiency), and I'd like to explore if we could remove some of the overlap. But, all kind of suggestions and requests are welcome! More importantly, I'd like to hear the opinions of the community about the general issue of a better time library! Do we need one? How should we proceed about it? I think, Haskell could potentially have one of the best time libraries, but the current de-facto standard is mediocre at best. Unfortunately, designing a good time library is very far from trivial, as many existing examples demonstrate. And I definitely don't know enough for it. (I understand time zone info files, now that I wrote tz, but that's just a tiny fraction of what's needed.) So, if you think you can contribute to the design (have important use-cases in mind, know good examples of API, have some experience working with dates and time, etc. etc.) ‒ speak up! Mihaly Footnotes: [1] http://hackage.haskell.org/package/time [2] http://hackage.haskell.org/package/tz [3] http://hackage.haskell.org/package/thyme [4] http://hackage.haskell.org/package/tz-0.0.0.1/docs/Data-Time-Zones.html#v:u… [5] http://hackage.haskell.org/package/timezone-series [6] http://hackage.haskell.org/package/timezone-olson

4 9

Domain Events in haskell
by Rouan van Dalen 07 Apr '14

07 Apr '14

Hi Cafe, I am trying to write a very simple implementation of an event publisher pattern but I am stuck and do not know how to do this in Haskell. I have the following code: ======================== {-# LANGUAGE RankNTypes, NamedFieldPuns #-} module Domain.DomainEventPublisher where import Control.Monad (forM_) import HsFu.Data.DateTime import Domain.Client data DomainEvent = ClientChangeAgeDomainEvent data DomainEventContext = DomainEventContext { domainEventContext_event :: DomainEvent , domainEventContext_occurredOn :: DateTime } deriving (Show) data DomainEventPublisher = DomainEventPublisher { domainEventPublisher_subscribers :: [DomainEventContext -> IO ()] } mkEventPublisher :: DomainEventPublisher mkEventPublisher = DomainEventPublisher [] subscribe :: DomainEventPublisher -> (DomainEventContext -> IO ()) -> DomainEventPublisher subscribe publisher eventHandler = DomainEventPublisher { domainEventPublisher_subscribers = eventHandler : (domainEventPublisher_subscribers publisher) } publish :: DomainEventPublisher -> DomainEventContext -> IO () publish DomainEventPublisher{ domainEventPublisher_subscribers } event = forM_ domainEventPublisher_subscribers ($ event) ======================== My problem is that the publish method returns IO (), which means that events can only be published from the IO monad, but I would like events to be 'publish-able' from pure code. I can live with event handlers (passed into the subscribe function) being in the IO monad. Is there a better way to implement this pattern in Haskell? I have been racking my brain on this for a while now and cannot seem to come up with a good implementation. Regards --Rouan.

3 2

ANN: Simon Marlow & Edward Kmett @ ZuriHac 2014
by Bas van Dijk 06 Apr '14

06 Apr '14

Dear Haskellers and ZuriHac 2014 attendees, On this lovely day (pun intended), I'm excited to announce that Simon Marlow and Edward Kmett will be giving talks at ZuriHac 2014. When: Friday 6 June 2014 - Sunday 8 June 2014 Where: Erudify offices, Zurich, Switzerland ZuriHac is an international Haskell hackathon: a grassroots, collaborative coding festival with a simple focus, to build and improve Haskell libraries, tools, and infrastructure. This is a great opportunity to meet your fellow Haskellers in real life, find new contributors for your project, improve existing libraries and tools, or even start new ones! 30 people already signed up for ZuriHac 2014 but there's still room for more. If you wish to attend, please register by filling in this form: http://bit.ly/ZuriHac2014 Full details can be found on the wiki page: http://www.haskell.org/haskellwiki/ZuriHac2014 We look forward to seeing you there! -- The organisers of ZuriHac 2014 ZuriHac 2014 is sponsored by Erudify & Google

3 4

GHC and platform versions
by Ian Zimmerman 06 Apr '14

06 Apr '14

On the Haskell Platform webpage, it tells me what GHC version I need for the latest/current version of the platform. Also, there are links to downloads for prior versions of the platform. But, how can I find out what GHC version I need for one of those older platform versions? That information doesn't seem to be on the page, and I see no README or similar file in the platform source tarball itself. -- Please *no* private copies of mailing list or newsgroup messages. gpg public key: 2048R/984A8AE4 fingerprint: 7953 ADA1 0E8E AB57 FB79 FFD2 360A 88B2 984A 8AE4 Funny pic: http://bit.ly/ZNE2MX

2 1

design problem, "varying intermediate types"
by Robert Vollmert 04 Apr '14

04 Apr '14

Dear cafe, I’m working on a project that reads logic puzzle descriptions from yaml files and renders them using the Diagrams framework (https://github.com/robx/puzzle-draw) and am quite unsure what’s a good way of stringing things together. It’s a bit hard to even express the problem… I’ve tried to break it down with limited success, to the following task: 1. Read YAML data like type: “three” x: 3 y: [3, 4, 5] Type is from a fixed (long) list of strings. This type determines the format of the fields x and y (x is required, y is optional). 2. Do something type-specific to produce output based on the parsed data. Two options, one that depends on the x field only, the second can also consult the y field. My problem is how I should deal with these intermediate types that vary based on the input. My current approach below has parsing and printing functions, and then one big function that strings the matching parsers and printers together. I’ve also thought about using one big sum type, or type classes (Parseable, Printable, but doesn’t really seem to help). So far, all of it has felt a bit awkward. Any suggestions for how to attack this much appreciated. Cheers Rob {-# LANGUAGE OverloadedStrings #-} import Control.Applicative import Data.Yaml type Parsers a b = (Value -> Parser a, Value -> Parser b) parse1 :: Parsers Int Double parse1 = (parseJSON, parseJSON) parse2 :: Parsers String Char parse2 = (parseJSON, parseJSON) -- parse3 :: Parsers Int [Int] -- ... lots more of these type Printers a b = (a -> IO (), a -> b -> IO ()) print1 :: Printers Int Double print1 = (print . show, \x y -> print (show y ++ "..." ++ show x)) print2 :: Printers String Char print2 = (const $ print "hello", \x y -> print (show y)) type Composed = (Value -> Parser (IO ()), Value -> Value -> Parser (IO ())) compose :: Parsers a b -> Printers a b -> Composed compose (pp, ps) (rp, rs) = (\v -> rp <$> pp v, \v w -> rs <$> pp v <*> ps w) composeType :: String -> Composed composeType t = case t of "one" -> compose parse1 print1 "two" -> compose parse2 print2 _ -> (f, const f) where f = fail $ "unknown type: " ++ t parseXY :: (String -> Value -> Value -> Parser a) -> Value -> Parser a parseXY f (Object v) = do t <- v .: "type" x <- v .: "x" y <- v .: "y" f t x y parseX :: (String -> Value -> Parser a) -> Value -> Parser a parseX f (Object v) = do t <- v .: "type" x <- v .: "x" f t x printA :: Value -> Parser (IO ()) printA = parseX (fst . composeType) printB :: Value -> Parser (IO ()) printB = parseXY (snd . composeType) main = do flagB <- return False -- command line flag let p = parseEither $ if flagB then printB else printA mv <- decodeFile "input.yaml" v <- maybe (fail "failed to parse yaml") return mv case p v of Left e -> fail $ "failed to parse data: " ++ e Right x -> x

2 3

Inline makes program slow?
by Kai Zhang 03 Apr '14

03 Apr '14

Hi cafe, Inline sometimes can cause problems, at least in following case: import qualified Data.Vector as V import Data.List f ∷ String → (String → Int → Char) → [Int] → String f str g idx = map (g str) idx h ∷ String → Int → Char *{-# INLINE h #-}* h s i = (V.fromList $ sort s) V.! i slow ∷ String → [Int] → String slow str = f str h fast ∷ String → [Int] → String fast str = map ((V.fromList $ sort str) V.!) main = do let testString = replicate 100000 'a' iterations = replicate 1000 100 putStrLn $ fast testString iterations putStrLn $ slow testString iterations Without inline (remove the inline pragma), "slow" would be much faster. I suspect this is because ghc can build a "persistent structure" for the partial applied function. After inline, each call of "g" will try to build a new vector. How can I tell ghc not to inline some specific functions? Or are there other ways to resolve this issue?

6 5

Re: [Haskell-cafe] Haskell Weekly News
by Roman Cheplyaka 01 Apr '14

01 Apr '14

(This was submitted to glasgow-haskell-users, probably by mistake. Redirecting to cafe.) * harry <voldermort(a)hotmail.com> [2014-03-31 00:36:10-0700] > There hasn't been a HWN since mid-December. I've emailed the editor with no > response, and there doesn't seem to have been any (public) online activity > from him since. > > I hope he's OK, but either way, it seems that HWN needs a new editor. Any > volunteers? While we're at it, I suggest to potential editors to look up how HWN looked back when Brent Yorgey was the editor. IMO it was much more interesting to read than a mechanically compiled list of reddit and SO posts which HWN has become lately. That style is more time and effort consuming, though. (http://ro-che.info/ccc/06) Roman

3 3

groupBy without Ord?
by martin 31 Mar '14

31 Mar '14

Hello all, when I groupBy a list in order to cluster elements which satisfy some sort of equality, I usually have to sort the list first, which requires Ord. However groupBy itself does not require Ord, but just Eq. How can I groupBy a List whose elements are only instances of Eq but not of Ord?

9 19

ghc-mod v4.0.0
by Kazu Yamamoto 31 Mar '14

31 Mar '14

Hello, I'm happy to announce the release of ghc-mod v4.0.0. You can see its changelog here: http://hackage.haskell.org/package/ghc-mod-4.0.0/changelog This version provides an interactive command called ghc-modi. As you can guess, this makes syntax error highlighting much faster. The Emacs front-end resolves the "import hell". If you are an Emacs user, probably it is worth reading this page: http://mew.org/~kazu/proj/ghc-mod/en/emacs.html The entire documentation was re-written. Please give a look at it if you are interested: http://mew.org/~kazu/proj/ghc-mod/en/ P.S. This is not April fool. --Kazu

1 0