- Haskell-Cafe - Haskell.org

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

Building GHC 7.6 with 7.8
by Colin Watson 04 Apr '14

04 Apr '14

Hi, I'm trying to bootstrap GHC on a new architecture (Linux arm64/aarch64). I've been working with Karel Gardas from https://ghc.haskell.org/trac/ghc/ticket/7942, and with a few of my own naïve modifications on top of his patch set I've been able to bootstrap my way to a complete working build of the ghc-7.8 git branch (that is, I was able to cross-build on amd64 and then do a complete native build on arm64). arm64 hardware is still pretty rare and emulation is slow, but I have access to some via work, so given help from somebody who knows GHC rather better than I do I'm in a good position to get this done. What I actually want is to see if I can get this support into Ubuntu 14.04 LTS, which is going to be released in about two weeks. I still just about have enough time to do this if I'm quick. However, we currently ship GHC 7.6.3, it's working pretty well, and I don't want to destabilise things by trying to introduce a new version of GHC even just for some architectures. Thus, I've been trying to build 7.6 using 7.8. I know this is not a supported path - it's pretty obvious from the ways it breaks that nobody has spent much time trying to make it work. It seems as though it ought to be possible in theory, though, and cross-building has improved so much in 7.8 that I really don't want to go back and try to cross-build 7.6 - I tried that before and never managed to get anywhere. I've therefore been trying to apply the obvious tweaks like adding imports and adjusting versions in .cabal files. However, I've run into a roadblock, and I hope somebody here might be able to figure out what's going on. I've attached my current work-in-progress patch set; there's some noise from autoreconf, and it also requires putting an updated libffi tarball in place. I've also attached a script(1) log of a failed build attempt. The patch is actually slightly newer than the typescript, in that I realised that the GHC_CONVERT_CPU output needed to be "aarch64" not "arm64" in order for configuring libffi to work properly; this has no material effect on the build failure, though, and I hope it doesn't cause too much confusion. This typescript is from a build of 7.6 with the cross-compiled ghc-stage2. However, I also tried the same build with the native ghc-stage2 build that I'd bootstrapped off that, and the failure looks basically the same to my eye. If anyone thinks the difference might be important then I'd be happy to prepare an updated typescript, but it takes a while. I'd appreciate any suggestions people might have. Thanks, -- Colin Watson [cjwatson(a)ubuntu.com]

1 1

2nd CFP: FHPC'14 - Functional and High-Performance Computing - due May 15
by Ryan Newton 04 Apr '14

04 Apr '14

There a couple small bugs in the previous CFP. (Dates were right, but day of the week was wrong -- the due date is a Thursday.) Please see the corrected version below. ===================================================================== CALL FOR PAPERS FHPC 2014 The 2nd ACM SIGPLAN Workshop on Functional High-Performance Computing Gothenburg, Sweden September 4, 2014 https://sites.google.com/site/fhpcworkshops/ Co-located with the International Conference on Functional Programming (ICFP 2014) Submission Deadline: Thursday, 15 May, 2014 (anywhere on earth) ===================================================================== The FHPC workshop aims at bringing together researchers exploring uses of functional (or more generally, declarative or high-level) programming technology in application domains where high performance is essential. The aim of the meeting is to enable sharing of results, experiences, and novel ideas about how high-level, declarative specifications of computationally challenging problems can serve as maintainable and portable code that approaches (or even exceeds) the performance of machine-oriented imperative implementations. All aspects of performance critical programming and parallel programming are in-scope for the workshop, irrespective of hardware target. This includes both traditional large-scale scientific computing (HPC), as well as work targeting single node systems with SMPs, GPUs, FPGAs, or embedded processors. It is becoming apparent that radically new and well founded methodologies for programming such systems are required to address their inherent complexity and to reconcile execution performance with programming productivity. Every year, the FHPC workshop has an application area as a theme. Papers touching on this topic are especially encouraged, though all in-scope papers are welcomed. For FHPC 2014, the theme is "Heterogeneous computing". In the systems and parallelism communities, there has been a lot of work on programming systems with CPUs and GPUs (or other mixed parallel architectures), but in the programming languages community this idea has not received as much attention. At their best, high-level languages can have the degrees of flexibility necessary to abstract over platform differences. Proceedings: ============ Accepted papers will be published by the ACM and will appear in the ACM Digital Library. * Submissions due: Thursday, 15 May, 2014 (anywhere on earth) * Author notification: Sunday, 15 June, 2014 * Final copy due: Sunday, 22 June, 2014 Submitted papers must be in portable document format (PDF), formatted according to the ACM SIGPLAN style guidelines (2 column, 9pt format). See http://www.sigplan.org/authorInformation.htm for more information and style files. Typical papers are expected to be 8 pages (but up to four additional pages are permitted). Contributions to FHPC 2014 should be submitted via Easychair, at the following URL: * https://www.easychair.org/conferences/?conf=fhpc14 The submission site is now open. The FHPC workshops adhere to the ACM SIGPLAN policies regarding programme committee contributions and republication. Any paper submitted must adhere to ACM SIGPLAN's republication policy. PC member submissions are welcome, but will be reviewed to a higher standard. http://www.sigplan.org/Resources/Policies/Review http://www.sigplan.org/Resources/Policies/Republication Travel Support: =============== Student attendees with accepted papers can apply for a SIGPLAN PAC grant to help cover travel expenses. PAC also offers other support, such as for child-care expenses during the meeting or for travel costs for companions of SIGPLAN members with physical disabilities, as well as for travel from locations outside of North America and Europe. For details on the PAC programme, see its web page (http://www.sigplan.org/PAC.htm) Programme Committee: ==================== Mary Sheeran (co-chair), Chalmers University of Technology, SE Ryan Newton (co-chair), Indiana University, USA Lennart Augustsson, Standard Chartered Bank, UK Jost Berthold, University of Copenhagen, Denmark Guy Blelloch, Carnegie Mellon University, USA Marius Eriksen, Twitter, USA Clemens Grelck, University of Amsterdam, Netherlands Vinod Grover, Nvidia, USA Kevin Hammond, University of St. Andrews, UK Ben Lippmeier, University of New South Wales, Australia Liu (Paul) Hai, Intel, USA Rita Loogen, University of Marburg, Germany Greg Michaelson, Heriot-Watt University, UK Marc Pouzet, ENS Paris, France John Reppy, Univesity of Chicago, USA Tiark Rompf, Oracle Labs and EPFL, Switzerland Satnam Singh, Google, USA Dimitrios Vytiniotis, Microsoft Research, UK General Chairs: ==================== Jost Berthold University of Copenhagen

1 0

FLOPS 2014 call for participation (June 4-6, Kanazawa, Japan; early registration deadline on May 13)
by Eijiro Sumii 04 Apr '14

04 Apr '14

Dear colleagues, The registration for FLOPS 2014 (Twelfth International Symposium on Functional and Logic Programming, June 4-6, Kanazawa, Japan) is now open: http://www.jaist.ac.jp/flops2014/registration.html - Early registration deadline on May 13, 2014 - Program http://www.jaist.ac.jp/flops2014/program.html with invited talks by Ranjit Jhala, Shin-ya Katsumata, and Gabriele Keller - Sponsored by JSSST SIGPPL; in cooperation with ACM SIGPLAN, AAFS, and ALP - Proceedings to be published as LNCS 8475 - Hyakuman-goku Matsuri Festival http://www.kanazawa-tourism.com/eng/event/event2.php on the day after the symposium (June 7); accommodation can be extended on request basis via the registration site (use the comments field) - See http://www.jaist.ac.jp/flops2014/ for more information Thank you! FLOPS 2014 Program Co-Chairs Michael Codish and Eijiro Sumii

1 0

What should I use if I want both deriving SQL 'create table' from haskell types automatically and relational queries ?
by ducis 04 Apr '14

04 Apr '14

Persistent and acid-state are both 'No SQL' ? I guess there is only groundhog?

3 2

Fun and Profit with Stongly-Typed Data Schemas
by Chris Dornan 04 Apr '14

04 Apr '14

Folks, I will be giving a talk in London on Wednesday evening at Skills Matter on _api-tools_, a cool new Haskell package Iris Connect have been developing with Well Typed to help us with the new web platform. See the Skills Matter web site for details: https://skillsmatter.com/meetups/6201-fun-and-profit-with-stongly-typed-data -schemas Cheers, Chris

1 0

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

Haskell Weekly News: Issue 289
by Daniel Santa Cruz 03 Apr '14

03 Apr '14

Welcome to issue 289 of the HWN, an issue covering crowd-sourced bits of information about Haskell from around the web. This issue covers from March 1 to 31, 2014 So... where have I been? My wife and I recently welcomed into the world our new baby, and as some of you have already experienced, I was doing good getting *some* sleep at night. Life has slowly started to get back to a more predictable rhythm, and I am sure glad to be back doing this. For a while there I thought that any project of mine before bambina was going to have to be put into permament hold, but things are getting very manageble now. Sorry for the abscense! I was somewhat pleased to see that some in -cafe wondered if this was coming back... this one is for you! Some have mentioned that they wish to see more of the "reviews" that HWN used to have of blog entries, and/or email chains in the different mailing lists. I understand that dessire. I'm probably going to need some extra hands to write those, if there are to be back. Maybe we can start with something "lighter", a la tl;dr. I'm stil trying to work out how we'd do that exacly. I'll keep you all posted. Anyway, enough rambling. Quotes of the Week * acowley: I will push machines-concurrent to hackage one fine day edwardk: not concurrent-machines ? acowley: Man, I walked right into that bike shed * malc: I have a coworker who constantly reads haskell stuff at work, nudged him towards the lens talk, that should push him towards actually doing work at work. * Fuuzetsu: I know someone who pulls in Lens just for & and ?? * Eduard_Munteanu: Don't put your money in monads, you can never get it back. :P Top Reddit Stories * Haskell for all: Introductions to advanced Haskell topics Domain: haskellforall.com, Score: 121, Comments: 23 On Reddit: [1] http://goo.gl/M6ZL9f Original: [2] http://goo.gl/YEKyCc * GHC 7.8.1 RC2 released Domain: well-typed.com, Score: 99, Comments: 36 On Reddit: [3] http://goo.gl/jxlLQl Original: [4] http://goo.gl/05xnqX * Book review: Parallel and Concurrent Programming in Haskell Domain: serpentine.com, Score: 87, Comments: 17 On Reddit: [5] http://goo.gl/BfWSWC Original: [6] http://goo.gl/nDe2UG * The Haskell Cast #6 - Gabriel Gonzalez and Michael Snoyman on Pipes and Conduit Domain: haskellcast.com, Score: 83, Comments: 13 On Reddit: [7] http://goo.gl/PwL2aV Original: [8] http://goo.gl/hwemr6 * Performance in Haskell from a noob's perspective Domain: self.haskell, Score: 74, Comments: 111 On Reddit: [9] http://goo.gl/IuT0uJ Original: [10] http://goo.gl/IuT0uJ * New Haddock -- a visual guide to changes Domain: fuuzetsu.co.uk, Score: 72, Comments: 13 On Reddit: [11] http://goo.gl/KWJSEh Original: [12] http://goo.gl/IXzESN * Full-time position available: computer scientist to create data types for scientific computing, in Haskell. Location: anywhere (telecommute). Domain: self.haskell, Score: 67, Comments: 17 On Reddit: [13] http://goo.gl/Z8y9py Original: [14] http://goo.gl/Z8y9py * Haskell Type Classes Cheatsheet Domain: fundeps.com, Score: 62, Comments: 21 On Reddit: [15] http://goo.gl/oAWk4C Original: [16] http://goo.gl/SqHbro * Malicious link in haskell.org docs for 6 years, 6 months, 6 days Domain: self.haskell, Score: 61, Comments: 6 On Reddit: [17] http://goo.gl/V5y3hk Original: [18] http://goo.gl/V5y3hk * What's your "killer app" for your scientific/statistical programming environment? Domain: self.haskell, Score: 57, Comments: 92 On Reddit: [19] http://goo.gl/jfbwdj Original: [20] http://goo.gl/jfbwdj * Find out the type of an expression/function with typed holes Domain: ro-che.info, Score: 56, Comments: 5 On Reddit: [21] http://goo.gl/hcjX1v Original: [22] http://goo.gl/TWLT5R * Elm 0.12 - making interactive UI elements easy and pure Domain: elm-lang.org, Score: 56, Comments: 5 On Reddit: [23] http://goo.gl/SRoog7 Original: [24] http://goo.gl/7FoFAz * QuickCheck 2.7 released Domain: hackage.haskell.org, Score: 55, Comments: 7 On Reddit: [25] http://goo.gl/RN66bR Original: [26] http://goo.gl/3S38Uz Top StackOverflow Questions * Why is Haskell unable to read "7e7" but able to read "7a7"? votes: 42, answers: 3 Read on SO: [27] http://goo.gl/ZI8qm8 * Strange GHCi lazy evaluation votes: 17, answers: 1 Read on SO: [28] http://goo.gl/aoHvVp * Fast, branchless unsigned int absolute difference votes: 16, answers: 3 Read on SO: [29] http://goo.gl/TT3Oxi * How can I write human-language units as postfixes in Haskell, like `3 seconds`? votes: 15, answers: 2 Read on SO: [30] http://goo.gl/6MJk5C * Running Haskell on Xeon-Phi votes: 14, answers: 1 Read on SO: [31] http://goo.gl/QEIayp Until next time, [32]+Daniel Santa Cruz References 1. http://www.haskellforall.com/2014/03/introductions-to-advanced-haskell-topi… 2. http://www.reddit.com/r/haskell/comments/21bcb5/haskell_for_all_introductio… 3. http://www.well-typed.com/blog/87 4. http://www.reddit.com/r/haskell/comments/1zgaln/ghc_781_rc2_released/ 5. http://www.serpentine.com/blog/2014/03/18/book-review-parallel-and-concurre… 6. http://www.reddit.com/r/haskell/comments/20sdt4/book_review_parallel_and_co… 7. http://www.haskellcast.com/episode/006-gabriel-gonzalez-and-michael-snoyman… 8. http://www.reddit.com/r/haskell/comments/1zfo9g/the_haskell_cast_6_gabriel_… 9. http://www.reddit.com/r/haskell/comments/21g6uo/performance_in_haskell_from… 10. http://www.reddit.com/r/haskell/comments/21g6uo/performance_in_haskell_from… 11. http://fuuzetsu.co.uk/blog/posts/2014-03-24-New-Haddock-released%21-A-visua… 12. http://www.reddit.com/r/haskell/comments/218rov/new_haddock_a_visual_guide_… 13. http://www.reddit.com/r/haskell/comments/202pvl/fulltime_position_available… 14. http://www.reddit.com/r/haskell/comments/202pvl/fulltime_position_available… 15. http://fundeps.com/posts/cheatsheets/2014-03-04-cheat-sheets/ 16. http://www.reddit.com/r/haskell/comments/1zn3h9/haskell_type_classes_cheats… 17. http://www.reddit.com/r/haskell/comments/21959m/malicious_link_in_haskellor… 18. http://www.reddit.com/r/haskell/comments/21959m/malicious_link_in_haskellor… 19. http://www.reddit.com/r/haskell/comments/1zowv1/whats_your_killer_app_for_y… 20. http://www.reddit.com/r/haskell/comments/1zowv1/whats_your_killer_app_for_y… 21. http://ro-che.info/articles/2014-03-13-type-of-local-function.html 22. http://www.reddit.com/r/haskell/comments/20bixd/find_out_the_type_of_an_exp… 23. http://elm-lang.org/blog/announce/0.12.elm 24. http://www.reddit.com/r/haskell/comments/218isr/elm_012_making_interactive_… 25. http://hackage.haskell.org/package/QuickCheck-2.7.1/changelog 26. http://www.reddit.com/r/haskell/comments/213da9/quickcheck_27_released/ 27. http://stackoverflow.com/questions/22689122/why-is-haskell-unable-to-read-7… 28. http://stackoverflow.com/questions/22491700/strange-ghci-lazy-evaluation 29. http://stackoverflow.com/questions/22445019/fast-branchless-unsigned-int-ab… 30. http://stackoverflow.com/questions/22109333/how-can-i-write-human-language-… 31. http://stackoverflow.com/questions/22253311/running-haskell-on-xeon-phi 32. https://plus.google.com/105107667630152149014/about

3 2

I guess this is "Play it again Sam"?? If so, sorry ...
by Vasili I. Galchin 03 Apr '14

03 Apr '14

http://www.infoq.com/presentations/haskell-newsroom-nyt

1 0

Eta Reduction
by Dan Doel 03 Apr '14

03 Apr '14

In the past year or two, there have been multiple performance problems in various areas related to the fact that lambda abstraction is not free, though we tend to think of it as so. A major example of this was deriving of Functor. If we were to derive Functor for lists, we would end up with something like: instance Functor [] where fmap _ [] = [] fmap f (x:xs) = f x : fmap (\y -> f y) xs This definition is O(n^2) when fully evaluated,, because it causes O(n) eta expansions of f, so we spend time following indirections proportional to the depth of the element in the list. This has been fixed in 7.8, but there are other examples. I believe lens, [1] for instance, has some stuff in it that works very hard to avoid this sort of cost; and it's not always as easy to avoid as the above example. Composing with a newtype wrapper, for instance, causes an eta expansion that can only be seen as such at the core level. The obvious solution is: do eta reduction. However, this is not operationally sound currently. The problem is that seq is capable of telling the difference between the following two expressions: undefined \x -> undefined x The former causes seq to throw an exception, while the latter is considered defined enough to not do so. So, if we eta reduce, we can cause terminating programs to diverge if they make use of this feature. Luckily, there is a solution. Semantically one would usually identify the above two expressions. While I do believe one could construct a semantics that does distinguish them, it is not the usual practice. This suggests that there is a way to not distinguish them, perhaps even including seq. After all, the specification of seq is monotone and continuous regardless of whether we unify ⊥ with \x -> ⊥ x or insert an extra element for the latter. The currently problematic case is function spaces, so I'll focus on it. How should: seq : (a -> b) -> c -> c act? Well, other than an obvious bottom, we need to emit bottom whenever our given function is itself bottom at every input. This may first seem like a problem, but it is actually quite simple. Without loss of generality, let us assume that we can enumerate the type a. Then, we can feed these values to the function, and check their results for bottom. Conal Elliot has prior art for this sort of thing with his unamb [2] package. For each value x :: a, simply compute 'f x `seq` ()' in parallel, and look for any successes. If we ever find one, we know the function is non-bottom, and we can return our value of c. If we never finish searching, then the function must be bottom, and seq should not terminate, so we have satisfied the specification. Now, some may complain about the enumeration above. But this, too, is a simple matter. It is well known that Haskell programs are denumerable. So it is quite easy to enumerate all Haskell programs that produce a value, check whether that value has the type we're interested in, and compute said value. All of this can be done in Haskell. Thus, every Haskell type is programatically enumerable in Haskell, and we can use said enumeration in our implementation of seq for function types. I have discussed this with Russell O'Connor [3], and he assures me that this argument should be sufficient even if we consider semantic models of Haskell that contain values not denoted by any Haskell program, so we should be safe there. The one possible caveat is that this implementation of seq is not operationally uniform across all types, so the current fully polymorphic type of seq may not make sense. But moving back to a type class based approach isn't so bad, and this time we will have a semantically sound backing, instead of just having a class with the equivalent of the current magic function in it. Once this machinery is in place, we can eta reduce to our hearts' content, and not have to worry about breaking semantics. We'd no longer put the burden on programmers to use potentially unsafe hacks to avoid eta expansions. I apologize for not sketching an implementation of the above algorithm, but I'm sure it should be elementary enough to make it into GHC in the next couple versions. Everyone learns about this type of thing in university computer science programs, no? Thoughts? Comments? Questions? Cheers, -- Dan [1] http://hackage.haskell.org/package/lens [2] http://hackage.haskell.org/package/unamb [3] http://r6.ca/

8 18