- Haskell-Cafe - Haskell.org

'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%3DHwphL%2B--V7j3Xftt%3D8drrZDuOQtcB38rPPkJ2w(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

Host-Oriented Template Haskell
by Ericson, John 19 Jan '16

19 Jan '16

As is well known, TH and cross-compiling do not get along. There are various proposals on how to make this interaction less annoying, and I am not against them. But as I see it, the problem is largely inherent to the design of TH itself: since values can (usually) be lifted from compile-time to run-time, and normal definitions from upstream modules to downstream modules' TH, TH and normal code must "live in the same world". Now this restriction in turn bequeaths TH with much expressive power, and I wouldn't advocate getting rid of it. But many tasks do not need it, and in some cases, say in bootstrapping compilers[1] themselves, it is impossible to use TH because of it, even were all the current proposals implemented. For these reason, I propose a new TH variant which has much harsher phase separation. Normal definitions from upstream modules can not be used, lifting values is either not permitted or is allowed to fail (because of missing/incompatible definitions), and IO is defined to match the behavior of the host, not target, platform (in the cross compiling case). The only interaction between the two phases is that quoted syntax is resolved against the the run-time phase's definitions (just like today). Some of you may find this a shoddy substitute for defining a subset of Haskell which behaves identically on all platforms, and optionally constraining TH to it. But the big feature that my proposal offers and that one doesn't is to be able to independently specify compile-time dependencies for the host-oriented TH---this is analogous to the newish `Setup.hs` dependencies. That in turns leads to what I think is the "killer app" for Host-Oriented TH: exposing the various prepossessors we use (alex, happy, hsc2hs, even CPP) into libraries, and side-stepping any need for "executable dependencies" in Cabal. Note also that at least hsc2hs additionally requires host-IO---there may not even exist a C compiler on the target platform at all. Finally, forgive me if this has been brought up before. I've been thinking about this a while, and did a final pass over the GHC wiki to make sure it wasn't already proposed, but I could have missed something (this is also my first post to the list). John [1]: https://github.com/ghcjs/ghcjs/blob/master/lib/ghcjs-prim/GHCJS/Prim/Intern…

1 0

Re: [Haskell-cafe] [ANNOUNCE] Haskell DBMS: Project:M36
by A.M. 19 Jan '16

19 Jan '16

On 12/21/2015 11:30 AM, Rémi Vion wrote: > Hello, Project:M36 seems amazing, thanks ! > Thank your also for the link to the "/Out of the Tar Pit" paper/ > (http://shaffner.us/cs/papers/tarpit.pdf > <http://shaffner.us/cs/papers/tarpit.pdf>). Thank you Remi. We are working on completing the final components described in precisely this paper. Then, we will publish an essay about how Project:M36 meets the paper's requirements for functional-relational programming. > > Are you aware of people using Project:M36 in production ? The project is very young and unlikely to be used in production. Currently, I would recommend it to users interested in learning about the mathematics behind the relational algebra. In comparison, SQL is a terrible platform for learning about the relational algebra because SQL made some poor historical decisions. Here is an essay on one facet of this argument: https://github.com/agentm/project-m36/blob/master/docs/on_null.markdown > Is there some user feedback available somewhere ? Please use the github issue system if you encounter any problems. Or are you asking for a "frequently-asked questions" section? We should certainly add that. > For small scale applications, do you think M36 is ready enough to be a > viable alternative to Postgres ? Project:M36 would be a viable replacement for PostgreSQL for experimental use only. There are many more optimizations at every level which need to be implemented before Project:M36 is on-par with PostgreSQL and we are working on many new features. Project:M36 has also not yet achieved feature parity with PostgreSQL, though Project:M36 already includes some features impossible in PostgreSQL (such as nested relations). Thanks for trying Project:M36! Any feedback you have would be very valuable. Cheers, M

1 0

Stackage is reverting to aeson-0.9
by Dan Burton 19 Jan '16

19 Jan '16

This means that LTS 4 is being discontinued, and LTS 5 is imminent. See the announcement blog post: https://unknownparallel.wordpress.com/2016/01/18/stackage-is-reverting-to-a… See also related discussion (yesterday): https://www.reddit.com/r/haskell/comments/41gpdk/lts4_with_aeson010_is_bein… If there are any questions or concerns, don't hesitate to ping me. -- Dan Burton

1 0

Haskell dev roles with Strats at Standard Chartered
by Don Stewart 18 Jan '16

18 Jan '16

Hi folks, I'm hiring 3 more devs to write Haskell for Standard Chartered in London and Singapore. Details of the roles below, but broadly in FX algo pricing and pricing automation. Ability to write "tight" total Haskell that can run 24/7 and do the right thing is needed. https://donsbot.wordpress.com/2016/01/18/haskell-developer-roles-at-standar… CVs to me at Standard Chartered -- Don

1 0