January 2016 - Haskell-Cafe

Haskell Weekly News
by Kim-Ee Yeoh 22 Jan '16

22 Jan '16

Dear Gentle Reader, Many, many beautiful gems in the Haskell Weekly News archives are worth a second look. To give you a taste, I reproduce below excerpts from the quotes section of the Jan 31, 2007 issue -- yes, that's 9 years ago -- under the editorship of Don Stewart. Enjoy. Best, Kim-Ee Yeoh *Top Picks* - Edsko de Vries designs O(1)-amortized and O(1)-worst-case queues <http://www.well-typed.com/blog/2016/01/efficient-queues/> using a technique different from the standard literature by Chris Okasaki. In particular, the O(1)-worst-case queue employs a Progress datatype that could be reused to also optimize data structures other than queues. On the other hand, Lennart Augustsson on /r/haskell was pleased as a plum until he saw the unsafeInterleaveST <https://www.reddit.com/r/haskell/comments/412n6n/new_blog_post_efficient_am…> required to pull off the Progress technique. Elsewhere, Hacker News rates the article highly enough <https://news.ycombinator.com/item?id=10913720> for it to stay on the front page for five hours <http://hnrankings.info/10913720/>. However, the comments there belie that the advanced Haskell goes swoosh over the head of the average HN reader. - Philipp Schuster sketches a FRP implementation based on temporal logic <http://haskellexists.blogspot.com/2016/01/frp-for-free.html>. Neel Krishnaswami explains on /r/haskell why it suffers from space leaks <https://www.reddit.com/r/haskell/comments/40x4wf/frp_for_free/> like most other FRP implementations and ways of fixing it. - Dan Burton reports that the latest version 0.10 of the json parsing package aeson suffers from deal-breaking bugs <https://unknownparallel.wordpress.com/2016/01/14/what-to-do-with-aeson-0-10/>. Aeson author Bryan O'Sullivan, of an older email-centered generation, explains that he has "a life outside of checking github issues" in the /r/haskell discussion <https://www.reddit.com/r/haskell/comments/4101ad/what_to_do_with_aeson010/>. In any case, the next stepping 5 of Stackage LTS rolls it back to version 0.9 <https://www.reddit.com/r/haskell/comments/41gpdk/lts4_with_aeson010_is_bein…> . - A redditor asks, "What's the TypeInType extension planned for the upcoming version 8 of GHC?" The short answer is that it's used for dependent type programming. Detailed answers can be found in the actual /r/haskell Q&A <https://www.reddit.com/r/haskell/comments/4180k3/what_is_typeintype/>. - GHC on ARM used to suffer over 100 failures on the testsuite <https://ghc.haskell.org/trac/ghc/ticket/11206>. Ben Gamari girds his loins and over the last 6 weeks battled against "the villains that plague this poor architecture." Result? Nightly builds now compile clean. Go Ben! *A Blast from the Past (Quotes from #Haskell IRC):* <http://sequence.complete.org/hwn/20070131> - *huschi:* Programing in haskell seems a bit frustrating. i'm missing searching for errors :( - *bakert:* I know all my programs can be reduced to only one tenth the size if only I can learn all these crazy functions *Quote of the Week* - Will Jones: The more I write Haskell, the more it feels like Forth. Where I'm basically just inventing a language for my problem, then writing the program in that instead. (Ed. Dear Will: Remember how Dijkstra once said "Always design your programs as a member of a whole family of programs, including those that are likely to succeed it"? He would have warmly congratulated you on your discovery.) -- Kim-Ee Yeoh

1 0

Munich Haskell Meeting, 2016-01-25 @ 19:30
by Christian Neukirchen 21 Jan '16

21 Jan '16

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Monday, January 25 at Cafe Puck at 19h30. For details see here: http://chneukirchen.github.io/haskell-munich.de/dates If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-jan-2016/ Everybody is welcome! cu, -- Christian Neukirchen <chneukirchen(a)gmail.com> http://chneukirchen.org

1 0

an automatic refactoring idea
by Jeffrey Brown 21 Jan '16

21 Jan '16

I had a data structure with a redundant field [1]. I refactored to make that field go away. Here is the code [2]. The following is a simplification of it. I was using this type: data X = X1 | X2 Int To make the Int go away, I made a duplicate type: data X' = X1' | X2' Then, every function for which any argument was of type X, I similarly duplicated, replacing every X with X', X1 for X1', and X2 for X2'. Next I had to similarly duplicate every function that used one of those. And so on, and so on ... until eventually I was duplicating the tests. At that point I was able to determine from the duplicate tests that everything was working. There was a little more work involved than that, but the vast, vast majority of the edits that got me there were the simple duplication I just described. I looked once at automatic refactoring in Haskell and was either unimpressed or scared. I may not have understood what I was looking at enough to appreciate its power. Is there something that can do the refactoring described above? [1] The Int in a Tplt could be inferred from context, so keeping a duplicate of that information in the Tplt was dangerous, because it makes invalid state possible (e.g. if one is updated and not the other). So I decided to stop using it. [2] https://github.com/JeffreyBenjaminBrown/digraphs-with-text -- Jeffrey Benjamin Brown

2 1

localized memory management?
by Johannes Waldmann 20 Jan '16

20 Jan '16

Dear cafe, how would you approach this task: find (enumerate) those x from a list xs for which some computation is not successful within some resource bound (it weeds out uninteresting data, leaving just the hard cases, which will be treated later by other means) Input and result could be lazy lists, computations are pure. If the bounded resource is time, then I can use System.Timeout. This puts me into IO, but OK. Perhaps I want to do some logging output anyways. The problem is with bounding space. Assume that "computation on x" (sometimes) allocates a lot. Then the whole program will just die with "heap exhausted", while in fact I want to terminate just the computation on this x, garbage-collect, and continue. I could make the space usage explicit: each step of the computation could additionally compute a number that approximates memory usage. (Assume that this usage varies wildly with each step.) Then I can stop iterating when this reaches some bound. Or, I just compile the computation into a separate executable, and I call it (for each x) via the operating system, because there I can bound space (with ulimit) Is there some way to achieve this in Haskell land? - J.W.

6 5

'stack test --trace' fails
by Eric 20 Jan '16

20 Jan '16

I just upgraded Stack to v1.0.2 on Mac OS X. I naively ran 'stack test --trace' hoping to get better messages out of any errorWithStackTrace calls in my tests. After a long, successful build, the tests failed with the message 'Could not understand these extra arguments: +RTS -xc'. Am I doing something obviously wrong? Or is this a Stack bug? --Eric

1 0

[Template Haskell Question] On defining recursive templates.
by Dominik Bollmann 20 Jan '16

20 Jan '16

Hello Haskellers, I'm currently diving into Template Haskell and I just read the original TH paper [1]. There they give the following example of a generic zip function: -- | A generic zip function. Use (e.g.,) as $(zipN 3) xs ys zs. zipN :: Int -> ExpQ zipN n = [| let zp = $(mkZip n [| zp |]) in zp |] -- | Helper function for zipN. mkZip :: Int -> ExpQ -> ExpQ mkZip n contZip = lamE pYs (caseE (tupE eYs) [m1, m2]) where (pXs, eXs) = genPEs "x" n (pXSs, eXSs) = genPEs "xs" n (pYs, eYs) = genPEs "y" n allCons = tupP $ zipWith (\x xs -> [p| $x : $xs |]) pXs pXSs m1 = match allCons continue [] m2 = match wildP stop [] continue = normalB [| $(tupE eXs) : $(appsE (contZip:eXSs))|] stop = normalB (conE '[]) -- | Generates n pattern and expression variables. genPEs :: String -> Int -> ([PatQ], [ExpQ]) genPEs x n = (pats, exps) where names = map (\k -> mkName $ x ++ show k) [1..n] (pats, exps) = (map varP names, map varE names) This works as expected, e.g., `$(zipN 3) [1..3] [4..6] [7..9]' gives [(1,4,7),(2,5,8), (3,6,9)]. However, I found this definition of passing `[| zp |]' as a helper function slightly confusing, so I tried to make it more succinct and to call zipN directly in the recursion: zipN' :: Int -> ExpQ zipN' n = lamE pYs (caseE (tupE eYs) [m1, m2]) where (pXs, eXs) = genPEs "x" n (pXSs, eXSs) = genPEs "xs" n (pYs, eYs) = genPEs "y" n allCons = tupP $ zipWith (\x xs -> [p| $x : $xs |]) pXs pXSs m1 = match allCons continue [] m2 = match wildP stop [] continue = normalB [| $(tupE eXs) : $(appsE (zipN n:eXSs)) |] stop = normalB (conE '[]) This subtle change, however, causes the compiler to diverge and to get stuck at compiling splice `$(zipN' 3) [1..3] [4..6] [7..9]'... Could anyone explain to me why the first approach works, but the 2nd small deviation does not? Is it because the compiler keeps trying to inline the recursive call to (zip N) into the template indefinitely? Are there easier (more straightforward) alternative implementations to the (imo) slightly convoluted example of zipN from the paper? Any hints are very much appreciated. Thanks, Dominik. [1] http://research.microsoft.com/~simonpj/papers/meta-haskell/

2 1

CPU with Haskell support
by Henning Thielemann 20 Jan '16

20 Jan '16

Hi all, every now and then I think it would be cool to have a microprocessor that supports Haskell in a way. A processor where lazy evaluation is not overhead but an optimization opportunity, a processor that can make use of the explicit data dependencies in Haskell programs in order to utilize many computation units in parallel. I know of the Reduceron project, which evolves only slowly and if it somewhen is ready for use it is uncertain whether it can compete with stock CPUs since FPGA's need much more chip space for the same logic. I got to know that in todays x86 processors you can alter the instruction set, which is mainly used for bugfixes. Wouldn't it be interesting to add some instructions for Haskell support? However, I suspect that such a patch might be rendered invalid by new processor generations with changed internal details. Fortunately, there are processors that are designed for custom instruction set extensions: https://en.wikipedia.org/wiki/Xtensa Would it be sensible to create a processor based on such a design? I have no idea what it might cost, and you would still need some peripheral circuitry to run it. What could processor instructions for Haskell support look like? Has anyone already thought in this direction?

9 12

Re: [Haskell-cafe] Doc generation?
by Francesco Ariis 20 Jan '16

20 Jan '16

On Tue, Jan 19, 2016 at 04:24:24PM +1100, Noon Silk wrote: > Does anyone know what is happening here? > > Not a single one of the packages on > http://hackage.haskell.org/packages/recent has docs generated at the moment. > > Some older ones, upload this year, also do not - > http://hackage.haskell.org/package/pipes-concurrency Docs not being built can be quite frustrating; for those dark times I build them locally: http://ariis.it/static/articles/no-docs-hackage/page.html Living with a flaky WiFi, saves me from screaming at the monitor quite some times.

8 11

Re: [Haskell-cafe] CPU with Haskell support
by Thomas Bereknyei 20 Jan '16

20 Jan '16

There is a CPU being design with an interesting architecture. Take a look at the Mill CPU at millcomputing.com. A facsinating feature is the use of a belt of values vs registers. The values on the belt are immutable and fall off (~auto gc'd?) unless expressly saved or returned. It is also desined to make function calls very cheap. tomberek On Jan 20, 2016 3:49 AM, <haskell-cafe-request(a)haskell.org> wrote: Send Haskell-Cafe mailing list submissions to haskell-cafe(a)haskell.org To subscribe or unsubscribe via the World Wide Web, visit http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe or, via email, send a message with subject or body 'help' to haskell-cafe-request(a)haskell.org You can reach the person managing the list at haskell-cafe-owner(a)haskell.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Haskell-Cafe digest..." Today's Topics: 1. Re: Doc generation? (Patrick Redmond) 2. Re: Doc generation? (Mark Fine) 3. Host-Oriented Template Haskell (Ericson, John) 4. [ANN] ghc-mod-5.5.0.0: Happy Haskell Hacking (Daniel Gr?ber) 5. CPU with Haskell support (Henning Thielemann) 6. Re: Doc generation? (Noon Silk) 7. Re: Doc generation? (Mikhail Glushenkov) 8. Re: CPU with Haskell support (Auke Booij) 9. Re: CPU with Haskell support (Darren Grant) 10. Re: CPU with Haskell support (Henning Thielemann) 11. Re: CPU with Haskell support (Ben Lippmeier) 12. Re: CPU with Haskell support (Richard A. O'Keefe) 13. Re: CPU with Haskell support (Gleb Popov) 14. Re: Doc generation? (Sven Panne) 15. Re: Doc generation? (Mikhail Glushenkov) 16. Re: CPU with Haskell support (Joachim Durchholz) 17. Re: Doc generation? (Sven Panne) ---------------------------------------------------------------------- Message: 1 Date: Tue, 19 Jan 2016 08:39:20 -0800 From: Patrick Redmond <plredmond(a)gmail.com> To: "cabal-devel(a)haskell.org" <cabal-devel(a)haskell.org>, "haskell-cafe(a)haskell.org" <haskell-cafe(a)haskell.org> Subject: Re: [Haskell-cafe] Doc generation? Message-ID: <CAHUea4Ht0p8=HwphL+--V7j3Xftt=8drrZDuOQtcB38rPPkJ2w(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" I don't know what's happening with hackage, but if you're using stack in your workflow a simple workaround is to build docs locally and search them with a shell script. For example: $ stack haddock async And then muck around in .stack-work or ~/.stack. I've written a bash/fish script to do the search for you here: plredmond.github.io/posts/search-haddocks-offline.html On Tuesday, January 19, 2016, Francesco Ariis <fa-ml(a)ariis.it> wrote: > On Tue, Jan 19, 2016 at 04:24:24PM +1100, Noon Silk wrote: > > Does anyone know what is happening here? > > > > Not a single one of the packages on > > http://hackage.haskell.org/packages/recent has docs generated at the > moment. > > > > Some older ones, upload this year, also do not - > > http://hackage.haskell.org/package/pipes-concurrency > > Docs not being built can be quite frustrating; for those dark times I > build them locally: > > http://ariis.it/static/articles/no-docs-hackage/page.html > > Living with a flaky WiFi, saves me from screaming at the monitor quite > some times. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org <javascript:;> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >

2 1

[ANN] ghc-mod-5.5.0.0: Happy Haskell Hacking
by Daniel Gröber 19 Jan '16

19 Jan '16

I'm pleased to announce the release of ghc-mod 5.5.0.0! This is primarily a maintenance and bug fix release. We are releasing this as a major version bump as we are following a policy of not trying to keep API compatibility until v6.0 to enable us to clean up ghc-mod's internals and API. What's new? =========== * Cabal flags are now preserved across automatic reconfigurations When ghc-mod detects something influencing the cabal configuration has changed since the last invocation it will automatically reconfigure the project. Previously this would call 'cabal configure' without any additional options thus possibly reverting flags the user might have added to the configure command previously. Now we extract the current set of flags from the existing configuration and pass the appropriate options to the configure command. * Rewritten command-line parser (again) The home grown sub-command parser based on getopt has been a user experience disaster so we've replaced it using a new optparse-applicative based parser. This does have the unfortunate side effect that we had to remove support for some optional arguments we had supported previously thus breaking compatibility with very old frontends. * Remove CWD requirement from command-line tools In v5.4.0.0 we had to add a workaround for a nasty race condition in 'ghc-mod legacy-interactive' (ghc-modi) which added a requirement that all ghc-mod command line tools are run in the root of each project's directory. This limitation has now been removed. Frontends which have implemented this workaround should be compatible going forward but for performance reasons it is advisable to disable the workaround for versions after v5.5.0.0. * Various bug fixes and smaller improvements From the change log: * Fix cabal-helper errors when no global GHC is installed (Stack) * Support for spaces in file names when using legacy-interactive * Fix "No instance nor default method for class operation put" * Fix a variety of caching related issues * Emacs: Fix slowdown and bugs caused by excessive use of `map-file` * Emacs: Add ghc-report-errors to inhibit *GHC Error* logging What is ghc-mod? ================ ghc-mod is both a back-end program for enhancing editors and other kinds of development environments with support for Haskell and a library for abstracting the black magic incantations required to use the GHC API in various environments, especially Cabal and Stack projects. The library is used by ambitious projects like HaRe[1], mote[2] and haskell-ide-engine[3] Getting ghc-mod =============== GitHub: https://github.com/DanielG/ghc-mod Hackage: http://hackage.haskell.org/package/ghc-mod Editor frontends: - Emacs (native): https://github.com/DanielG/ghc-mod https://github.com/iquiw/company-ghc - Vim: https://github.com/eagletmt/ghcmod-vim https://github.com/eagletmt/neco-ghc - Atom: https://github.com/atom-haskell/ide-haskell Known issues ============ For issues other than the ones mentioned below visit our issue tracker: https://github.com/DanielG/ghc-mod/issues Frequently reported issues -------------------------- ghc-mod once compiled is bound to one version of GHC since we link against the GHC API library. This used to not be a very big problem but since Stack made it exceedingly easy for users to use more than one version of GHC without even knowing the number of problems in this area has exploded. We are tracing the issue in the following issue: https://github.com/DanielG/ghc-mod/issues/615 (Support switching GHC versions without recompiling ghc-mod) ghc-mod's `case`, `sig` and `refine` commands still do not work properly with GHC>7.10 (See https://github.com/DanielG/ghc-mod/issues/438) Unless someone volunteers to fix this issue I will work towards replacing the features using mote[2] instead as the current code is, from my point of view, unmaintainable. If you do notice any other problems please report them: https://github.com/DanielG/ghc-mod/issues/new ---- [1]: https://github.com/alanz/HaRe [2]: https://github.com/imeckler/mote [3]: https://github.com/haskell/haskell-ide-engine

1 0