- Haskell-Cafe - Haskell.org

Haskell Platform Plans
by Gershom B 13 Nov '15

13 Nov '15

Dear all, As you know, Mark has passed on the Haskell Platform maintainer hat to me. I wanted to give a heads-up on current plans to keep folks in the loop. This message has three sections, first the 7.10.3 release, next the 8.0 release, and finally some general musings on fiddly details and future plans. 1) 7.10.3 The 7.10.3 release candidates have been out for windows and unix for a bit. As I understand it there is still work underway on the mac build, but that will hopefully be coming shortly. The plan is to release a new platform roughly simultaneously. This platform will work essentially as in the past, for two reasons. First, because it is the last release in the 7.10 series and should be seen like the 7.10.3 compiler as just incorporating some necessary patches rather than any serious changes. Furthermore, the future plans underway rely on a few patches to cabal which have been merged, but are not yet in any existing cabal-install release. A few packages have received minor version bumps, as follows: PACKAGE 7.10.2-a latest ------------------------------------------- case-insensitive 1.2.0.4 1.2.0.5 fgl 5.5.2.0 5.5.2.3 GLUT 2.7.0.1 2.7.0.3 GLURaw 1.5.0.1 1.5.0.2 HUnit 1.2.5.2 1.3.0.0 OpenGL 2.12.0.1 2.13.1.0 OpenGLRaw 2.5.1.0 2.6.0.0 primitive 0.6 0.6.1.0 syb 0.5.1 0.6 scientific 0.3.3.8 0.3.4.2 StateVar 1.1.0.0 1.1.0.1 A few packages were held back due to dependency issues (notably zlib) and additionally, packages shipped with ghc were held back to the versions that will be shipped with 7.10.3. 2) 8.0 We also plan to ship a new platform concurrently with the ghc 8.0 that should be released early next year. That platform will implement some long-discussed and requested changes. First, the platform already ships with msys on windows. However, it does not do so in a way that lets you, as with minGHC, install the network library directly, or for that matter install directly other libraries that use build-type configure. This is because the msys binaries don't get placed into the path, by design. The new platform will ship with a newer cabal, incorporating a patch (pull request #2480) that uses the extra-prog-path setting for build-type: configure. This should allow network and other things reliant on build-type: configure to directly cabal install. The goal for the platform on windows will be that any packages binding to msys libraries _should_ be cabal installable without hassle. If you maintain a library that you think would be a good test-case for this, please drop a line so we can work together towards this goal. Second, the default platform will be _minimal_. That is to say that it will _only_ install into the global package database those packages that are directly shipped with ghc, and not any additional platform packages. "Blessed" platform packages will however still be shipped as a "default user cabal.config" file, so in a setting where users want to work unsandboxed, their versions of platform libs will remain pegged to those chosen by the platform, should they not choose to alter their settings. In a sandboxed setting, or in the presence of a local cabal.config generated by a freeze, those constraints will be disregarded. Furthermore, it is likely but not certain that the "nix-like cabal" or "no-reinstall cabal" will be available for the 8.0 release. If this is the case, users will be able to operate in an unsandboxed environment without conflicts, as multiple instances of the same version of a package, with different dependency choices, will be able to live side-by-side. Third, the platform will ship not only with cabal-install, but also with the stack tool, so that users can choose either workflow, depending on their project or preferences. A number of people have adopted the stack tool, and many beginners have reported success with it as well, so it will be good to provide that functionality out of the box with every platform install. Time and resources permitting we would also like to ship a platform version _with_ the platform libraries prebuilt and included, as that is also a use case that some people continue to like. However, this is a secondary priority, and contingent on us getting our build infrastructure into a good enough shape to make this not too much extra hassle. I'm excited about these changes, and confident we can get their in a timespan that matches the 8.0 release of ghc. 3) Generalities As I mentioned, it would be good to have a more uniform build infrastructure. Generally, I have put out some feelers and am working towards extending the ghc nightly buildbot infrastructure to both cover more platforms and also cover more tools -- not only ghc, but cabal, the platform, perhaps haddock, ghcjs, etc. This way we can get an economy of scale and many of our core tools will be able to all share regular automated builds across many platforms. If you like CI/buildbot systems and would like to help out with this project, please reach out. Also, once we've modernized and fixed up the core platform installer tech, it would be nice to move back to the process of making the platform a good set of blessed libraries -- taking more proposals for additions to it, looking to cull libraries that are no longer widely used, etc. As part of this I intend to move the haskell-platform list off our deprecated community.haskell.org infrastructure and onto mail.haskell.org with our other active lists. Finally, I'm happy to be maintainer of the platform through this period of change and transition, but at some future point, as things get sorted out and the release process becomes more standard and mechanical, I would very much like to pass this responsibility on. I have had some nibbles of offers, but if other people want to begin to get involved, please let me know and we can start to get small contributions from you so that you can become familiar with the various tech and systems involved. The Haskell ecosystem is a team effort, a collective project, and volunteer driven. In my modest experience hacking on the various systems involved (cabal, cabal-install, hackage, the platform build, etc.) some are a bit confusing, but I have always found helpful contributors willing to explain things and review patches, and to help think about and diagnose problems. And none of the code has been as confusing as things I've had to wade through for employment-related purposes :-). So when this stuff doesn't work as well as we'd like, we can investigate together, and then put our heads together and figure out how to improve it together. Furthermore, it can be very satisfying to do so, because the impact of those improvements makes itself widely felt. I look forward to more people joining in! Best, Gershom

1 0

Re: [Haskell-cafe] haskell-src-exts maintenance
by Matthew Pickering 13 Nov '15

13 Nov '15

Peter, Please can you do the release. I completed the work updating HSE several months ago, a much better version of HSE has been waiting on the master branch since then. I thank you for providing helpful review for the patches I submitted but since then I have sent three emails asking about the release. After the second you promised to do a release at the end of October but that never happened. It is a shame that the user's of HSE have had to live with many long standing bugs when they have been fixed for months. If you can not do it for whatever reason then please can you add me as a maintainer on hackage and the github repo so that users can get an updated version of HSE. Best wishes, Matt On Tue, Jul 28, 2015 at 11:35 PM, Peter A Jonsson <jonsson.peter.a(a)gmail.com> wrote: > I’m not even going to bother to CC haskell-cafe since that will just bounce or go into a black hole. > > I exchanged a couple of mails with David (Lemmih) and my impression was that he was going to act upon some things but I didn’t follow up on that so there was probably some miscommunication between the two of us. > > I’ve merged some things and reviewed some patches. I agree with Neil that stable things should be merged and the yearly release of HSE should be made. I don’t want to rush things out through the door at any cost though—I believe HSE’s users are better served by something that is a strict improvement and contains more features than the last release compared to something that has even more features but is a bit shaky and requires a new major version of HSE in just a month or two which would force the client code to be re-tested and re-released. > > Best Wishes, > > Peter > >> On 28 Jul 2015, at 17:49, Neil Mitchell <ndmitchell(a)gmail.com> wrote: >> >> As a very heavy HSE user (HLint and Hoogle), who has had a reasonably >> close working relationship with all of Niklas (my SoC mentor and my >> SoC mentee), Roman and Peter (a fellow supercompiler developer) and >> Matt (currently hacking on HLint), I thought I should weigh in. >> >> The current state of HSE is a little forlorn - there are 22 open pull >> requests, everything from reducing algorithm complexity (an accidental >> n^3), fixing the default encoding (should be UTF8) and lots of actual >> parser fixes. A lot of this is good stuff, and the high level of >> external contributions is a really good sign. But they need to be >> merged and reviewed, and it seems the bandwidth just isn't there at >> the moment. Given Matt's comments on the existing tickets, and the >> triage he's already performing on the repo, I have high hopes that >> Matt could provide a bit more of the time and attention. Peter, >> perhaps a co-maintainer would be good for a little while? >> >>> If it's not soon then please could you add myself and Christian to the >>> maintainers so that we can perform some short term maintenance. My >>> immediate plan of action would be >>> >>> 1. Immediately cut a 1.17 release from the master branch as it >>> contains much better parsing of lifted constructors which are becoming >>> more prevalent. >>> 2. Review and merge recent pull requests. >>> 3. Update the parser as far as possible with missing features. >>> 4. Release 1.18 with these improvements within 1 month. >> >> Awesome! Although as a preference I'd go for as much of 2 as you can >> in a couple of days before doing 1 - a lot of the patches are simple >> and valuable, and a 2 day wait isn't going to be too problematic. >> >> Thanks, Neil >

1 0

checking whether the list is active
by Miroslav Kocic 12 Nov '15

12 Nov '15

3 2

types calculation
by Dmitry Olshansky 12 Nov '15

12 Nov '15

Hello! It seems that types without parameters are not reduced in ghc unlike CAFs. I.e. if we have type T1 a b = ... type T2 = T1 Int Int than T2 will be calculated on each utilization. Is my statement correct? If so, why is it? With complicated type-calculation compile time is growing too fast. Best regards, Dmitry

2 4

Stack: Copying possible?
by Rustom Mody 11 Nov '15

11 Nov '15

Trying to switch over to stack I copied over ~/.stack to another Linux box And it gives me sanity check failed Machines are same -- both 64 bit ubuntu wily -- user-names are different and that shows in the error message. I'd like to avoid almost a Gb of repeated downloads if possible. But if thats not kosher that fine... Just asking :-)

3 4

Question, re: illegal instance error.
by David Banas 11 Nov '15

11 Nov '15

Hi all, I don’t understand why this code: 50: instance (IsNat n, RealFloat a) => FFT (RTree n) a where is generating this error: fft_test.hs:50:36: Illegal instance declaration for ‘FFT (RTree n) a’ (All instance types must be of the form (T a1 ... an) where a1 ... an are *distinct type variables*, and each type variable appears at most once in the instance head. Use FlexibleInstances if you want to disable this.) In the instance declaration for ‘FFT (RTree n) a’ and was hoping someone could help me get it. Thanks! -db

3 2

[ANN] SBV 5.4 is out
by Levent Erkok 10 Nov '15

10 Nov '15

I'm happy to announce a new release (v5.4) of SBV: SMT Based Verification. See: http://hackage.haskell.org/package/sbv New in this release is the 'sAssert' function, which allows boolean-assertions to be sprinkled in symbolic code, which can then be statically discharged (or shown violating assignments for) using the 'safe' function. See: http://hackage.haskell.org/package/sbv-5.4/docs/Data-SBV.html#g:39 A slightly larger example checks for lack-of-division-by-0 in a simple program: http://hackage.haskell.org/package/sbv-5.4/docs/Data-SBV-Examples-Misc-NoDi… Further documentation on SBV is available at: http://leventerkok.github.io/sbv/ Calls to sAssert calls are also preserved in the SBV->C compilation path. This feature is rather experimental and , and I'd love to hear if you give it a try and see any gotchas.. Happy proving. -Levent. PS. Thanks to Brett Letner for suggesting this functionality.

1 0

Anybody using the "top-down" cabal-install solver?
by Bardur Arantsson 09 Nov '15

09 Nov '15

(Sorry if you get this twice, forgot to cross-post to -cafe initially.) Hi all, Just to get input from as many people as possible: I was pondering a plan for modularizing[2] the Cabal solver[1] and wanted to reach as many people as possible with my question: Is anybody is still using the top-down solver? Please respond to this list if you are, especially if you're doing so because there's no other way to get the modular solver to do what you want. (Obviously, I'm not promising to fix any problems you may have with the modular solver, but it would be valuable information since it could affect the decision of whether we have to keep the top-down solver around.) Regards, -- [1] https://github.com/haskell/cabal/pull/2768#issuecomment-154917165 [2] "Splitting it out into its own library" is perhaps a more accurate description, but somewhat unwieldly :).

1 0

Where io-streams won't fit, comparing to conduit or pipes
by Daisuke Fujimura 09 Nov '15

09 Nov '15

Hello cafe, Now I'm preparing a presentatio for meetup for stream processing in functional programming(in Tokyo), and my part is something like "why stream processing library". While preparing material, I encountered the question that why io-streams is so simple comparing others, and the reason and downsides behind its simplicity. I'm guessing it's due to its resource handling strategy, but not so confident about it because I couldn't came up with a concrete example yet. Do you know any good example where io-streams won't fit? Let me know if you have. Thanks!

4 3

How to get GHC to produce ADC instructions for long addition
by Clinton Mead 09 Nov '15

09 Nov '15

Here is some code that adds two 192 bit numbers, represented as three 64bit machine words (well, on my machine anyway), and returns the result and any carry: {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} import GHC.Prim( plusWord2#, Word#, or#) longAdd :: (# Word#, Word#, Word# #) -> (# Word#, Word#, Word# #) -> (# Word#, (# Word#, Word#, Word# #) #) longAdd (# xl, xm, xh #) (# yl, ym, yh #) = let plusWord2WithCarry x y c = let (# c1, r1 #) = plusWord2# x y (# c2, r2 #) = plusWord2# r1 c in (# plusWord# c1 c2, r2 #) (# cl, rl #) = plusWord2# xl yl (# cm, rm #) = plusWord2WithCarry xm ym cl (# ch, rh #) = plusWord2WithCarry xh yh cm in (# ch, (# rl, rm, rh #) #) (My code covers words other than size 3 btw) I'd like this to compile into something like: add x1 y1 adc x2 y2 adc x3 y3 Unfortunately, I think my problem is with the "plusWord2WithCarry". As there's no primitive operation in Haskell which adds two words and a carry. What seems to happen when I look at the generated assembly is the following: xor some_reg_1 some_reg_1 add x1 y1 adc $0 some_reg_1 xor some_reg_2 some_reg_2 adc x2 y2 adc $0 some_reg_2 xor some_reg_3 some_reg_3 adc some_reg_1 y2 adc $0 some_reg_3 add some_reg_2 some_reg_3 ... and so on Basically, instead of just using the carry flag in add of the next two higher words, it instead saves it to a register, adds the next higher order words without the carry, clears a register and then adds the carry to this register, adds the first mentioned carry, against clears a register and saves that carry, combines the two resulting carries and passes it to the next higher order addition. I know that sounds complex, and the code is a bit of a mess. Bizarrely, when I send it through the LLVM backend it ends up worse, generating a bunch of 32 bit shifts for reasons I can't understand. I was hoping the LLVM backend would be able to produce the "adc" instructions. Is there anything I could do to coax it into it. I know writing it in C (or inline assembly in C) is an option, but after you add the code to call and return such a small amount of work it seems hardly worth it. I'd like to keep it in GHC so it can be inlined where appropriate. Any ideas on how to entice GHC (either natively or via LLVM) to produce better code in this case?

1 0