Last month, we announced the open sourcing of ide-backend, the engine underlying both School of Haskell and FP Haskell Center. In this blog post, I'm going to lay out FP Complete's plans for the future of both of those services, and our overall commercial Haskell tooling.
tl;dr Open sourcing School of Haskell, releasing brand new open source Stackage-based tooling, and merging the features of FP Haskell Center into the other two offerings.School of Haskell
School of Haskell has served as a foundational service for interactive Haskell training, written in a collaborative way. In our efforts to help increase adoption of Haskell, we've decided that the best next step for the evolution of School of Haskell is to fully open source it. Concretely, our plans are:
- Open up a new code base for School of Haskell, under the auspices of the Commercial Haskell Special Interest Group
- Host the site on its own dedicated domain name, http://www.schoolofhaskell.com/
- Set up redirects as necessary
- Make the content of School of Haskell much more open
- Make it easier to interact with the raw content of the school, possibly by storing the content in a Git repository that is publicly cloneable
- Encourage collaborators on the code base to get new features in place (and see the FP Haskell Center discussion below for more information on this from us)
To be clear: FP Complete fully intends to continue maintaining both the code base and the live servers. This move is intended to allow others to contribute their own, wonderful new ideas to the project.Stackage-based Tooling
FP Complete started the Stackage project about three years ago to address issues around library compatibility and collaborative development on teams, and it has been a resounding success. It's already the basis for School of Haskell and FP Haskell Center, and with Stackage Server is fully available to all users as an easy way to get sane package sets. We started LTS Haskell at the beginning of this year, which has only increased that success further.
Today's Stackage project answers a lot of the demand for better tooling, especially in the commercial realm. However, it doesn't answer everything. Companies we work with need solutions for everything from CI integration, to editor plugins, to deployment solutions. FP Haskell Center answers some of these demands, but not all of them. Over the past year, we've been working with our customers to develop a commercial grade set of tools that solve these problems more holistically, and we are happy with the result.
Our new tooling is integrated tightly with Stackage, provides improvements to some flaws in currently available tooling, and adds in functionality not yet present at all in the open source world. For example:
- Distribution of binary package databases to your whole team, avoiding recompile time and ensuring consistent environments
- Reliable rebuilding of all local packages with a single command
- Built in documentation serving for your entire package set
- Powerful code exploration features
We feel comfortable with the quality of the tooling to now take it to the next step. So over the next few weeks, we will begin the process of open sourcing all of this tooling to the Haskell community. As we release components, we will be describing their functionality, explaining expected use cases, and documenting current shortcomings. But the short answer is: if you're working on developing Haskell applications, this tooling is likely to make your life significantly better.FP Haskell Center
This leaves the question: what of FP Haskell Center? We initially received a lot of requests from companies looking for a web based IDE. However, over the past two years, we have seen that- in reality- people were looking to solve two different use cases:
- For learners: an easy way to get started with learning Haskell
- For application writers: a reliable set of tools for developing, building, and shipping software
After careful consideration, we believe that the two offerings mentioned above- School of Haskell and Stackage-based tooling- are the best way forward, and that continuing to push FP Haskell Center as a development platform is not a good path forward. Instead, our goals are to take the best that FP Haskell Center has to offer, such as interactive type information, and make them available in both School of Haskell and our commercial tooling.
At the end of the day, we'll be offering two very complementary products: a hosted learning site for quickly getting up to speed with Haskell, and commercial grade tooling for writing software.Timeline
The first concrete step on this path is going to be our Stackage-based tooling work. We're hoping to get a first public version out the door in short order. The following step is open sourcing School of Haskell. Once that is fully done, we'll start the discussions around FP Haskell Center. It is still a service that many people use, and we have no intention of pulling the rug out from under people. Our timeline their will likely be to:
- leave FP Haskell Center running for quite a while
- when School of Haskell and Stackage-based tooling become solid enough offerings to replace it, officially deprecate it
- some time after that, stop offering FP Haskell Center as a separate service
We very much welcome community input on these plans. Let's kick off a discussion on Reddit.
Supposing I have these modules:module Private where a :: Int a = 3 module Public(module Public) where import Private as Public b :: Bool b = False
And the .cabal file has this:exposed-modules: Public other-modules: Private
In Haskell, from another package, if I do "import Public" I get access to both "a" and "b". I cannot do "import Private". This is what I want. I am doing this to aggregate many modules with small interfaces (but possibly large implementations) into one module interface for import.
But the haddock documentation for my package shows only "b", not "a" for "Public". Am I doing something wrong? Is this a bug in haddock? What's the nicest workaround?submitted by AshleyYakeley
[link] [7 comments]
I’ve now finished revising the paper that Dan Piponi and I had accepted to MPC 2015; you can find a PDF here:
Here’s the 2-minute version: certain operations or restrictions on functors can be described by regular expressions, where the elements of the alphabet correspond to type arguments. The idea is to restrict to only those structures for which an inorder traversal yields a sequence of types matching the regular expression. For example, gives you even-size things; gives you the derivative (the structure has a bunch of values of type , a single hole of type , and then more values of type ), and the dissection.
The punchline is that we show how to use the machinery of semirings, finite automata, and some basic matrix algebra to automatically derive an algebraic description of any functor constrained by any regular expression. This gives a nice unified way to view differentiation and dissection; we also draw some connections to the theory of divided differences.
I’m still open to discussion, suggestions, typo fixes, etc., though at this point they won’t make it into the proceedings. There’s certainly a lot more that could be said or ways this could be extended further.
This week I introduced myself to Recurse Center, where I will be in residence later this month, and mentioned:
I have worked as a professional programmer for a long time so I sometimes know strange historical stuff because I lived through it.
Ms. Nikki Bee said she wanted to hear more. Once I got started I had trouble stopping.
I got interested in programming from watching my mom do it. I first programmed before video terminals were common. I still remember the smell of the greasy paper and the terminal's lubricating oil. When you typed control-G, the ASCII BEL character, a little metal hammer hit an actual metal bell that went "ding!".
I remember when there was a dedicated computer just for word processing; that's all it did. I remember when hard disks were the size of washing machines. I remember when you could buy magnetic cores on Canal Street, not far from where Recurse Center is now. Computer memory is still sometimes called “core”, and on Unix your program still dumps a core file if it segfaults. I've worked with programmers who were debugging core dumps printed on greenbar paper, although I've never had to do it myself.
I frequented dialup BBSes before there was an Internet. I remember when the domain name system was rolled out. Until then email addresses looked like yuri@kremvax, with no dots; you didn't need dots because each mail host had a unique name. I read the GNU Manifesto in its original publication in Dr. Dobb's. I remember the day the Morris Worm hit.
I complained to Laurence Canter after he and his wife perpetrated the first large scale commercial spamming of the Internet. He replied:
People in your group are interested. Why do you wish to deprive them of what they consider to be important information??
which is the same excuse used by every spammer since.
I once worked with Ted Nelson.
I remember when Sun decided they would start charging extra to ship C compilers with their hardware, and how the whole Internet got together to fund an improved version of the GNU C compiler that would be be free and much better than the old Sun compiler ever was.
I remember when NCSA had a web page, updated daily, called “What's New on the World Wide Web”. I think I was the first person to have a guest book page on the Web. I remember the great land rush of 1996 when every company woke up at the same time and realized it needed a web site.
I remember when if you were going to speak at a conference, you would mail a paper copy of your slides to the conference people a month before so they could print it into books to hand out to the attendees. Then you would photocopy the slides onto plastic sheets so you could display them on the projector when you got there. God help you if you spilled the stack of plastic right before the talk.
tl;dr i've been around a while.
However, I have never programmed in COBOL.
(I'm not actually very old, but I got started very young.)
I just made a little library for parsing bower.json files in Haskell. I'd appreciate any feedback:hdgarrood
[link] [5 comments]
Basically, I've written a small library mimicking the functionality of [Control.Concurrent.Async][http://hackage.haskell.org/package/async-2.0.2/docs/Control-Concurrent-Async.html], with a few notable differences.
I'm currently calling this library Control.Concurrent.FutureIO and this is currently how I plan to submit the package to Hackage. Currently, there are only two functions that exist as a part of the API, async :: IO a -> FutureIO a and await :: FutureIO a -> IO a, instead of Async' s functions async :: IO a -> IO (Async a) and wait :: IO (Async a) -> IO a.
The benefit of my implementation (in my eyes) is that FutureIO is an instance of the Functor/Applicative/Monad classes and it composes neatly. For instance, the following code will only take ~1s instead of 3s to complete.wait1s = threadDelay 1000000 slowMulti = async $ wait1s >> return (*) slowProd1 = async $ wait1s >> return 42 slowProd2 = async $ wait1s >> return 24 await $ slowMulti <*> slowProd1 <*> slowProd2
Ignoring this incredibly trivial example, in my eyes this has a pretty strong benefit over the Control.Concurrent.Async package. My question is "Is there a better way for me to submit this than just under the FutureIO moniker?"
*(note: As a Haskell newbie, I'm fully aware that this could be dumb, redundant, etc. and I would love it if you told me so I could learn)submitted by cghio
[link] [10 comments]
It's been a few weeks since the last news bulletin - your editor apologizes about that. It's actually been a relatively slow few weeks here too, and busy-ness outside of GHC has attracted some of my attention. Despite that, GHC 7.10.1 was released, a new HP alpha is out, and things are moving along smoothly. Now that the release is done, things are quitely moving along in HEAD - with people committing code with reckless abandon, of course.
This week, GHC HQ met up, but it's been very light since the 7.10.1 release. Currently there isn't anything pushing us to do a 7.10.2 release at least for a few more weeks it looks like - but see below.
- We puzzled a bit about the release status of 7.10.2, and thought: it's only holding up people who are depending on it. So, who's depending on it, and what do they need fixed? See below for more.
- We also talked a bit about performance - it seems the compiler has been getting much slower over time since the 7.8.x release series, and it's time to reign it in. Austin will be spending his week investigating a bit of this, and the causes.
So, you may be wondering when the 7.10.2 release is. The trick is it happens when you tell us it should happen!
So far, taking a look at milestone:7.10.2, we've fixed about half the bugs we currently have marked down to fix. But we're probably going to punt some of those - and we're not sure all the ones that are there should be.
So this is a call: If you need something to be fixed during 7.10.2, please file a ticket, set the milestone, and alert us. The sooner the better, because it'll inform us as to when we should release. Emailing firstname.lastname@example.org is also a sure-fire way to get our attention.
And remember: you can always find out the latest about the next release at the Status page (in this case, for 7.10.2) - https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2Call for help: DocBook to AsciiDoc
The GHC team needs some help. A few months ago, we put out a poll to convert our DocBook-based manual to AsciiDoc.
The poll had a mostly lukewarm reception, with the idea that it will A) make life easier for people who frequently modify the users guide, and B) make life easier for people who add things irregularly, as a lower barrier to entry.
It looks like we still want to do this - but alas, many of us don't have time!
So, we're asking the public: Is anyone willing to step up and help here? For example, it may be possible to get a long ways with just pandoc, but we need someone to finish it - and in return, we'll help along the way!List chatter
- Austin Seipp announced GHC 7.10.1. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008700.html
- Mark Lentczner announced an alpha Haskell Platform release. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008724.html
- David Macek announced MSYS2 packages for GHC on Windows, and also asked for some help with continuous windows building - Windows hackers should help out! https://mail.haskell.org/pipermail/ghc-devs/2015-March/008735.html
- Jan Stolarek reports about increased memory usage with GHC 7.10.1. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008751.html
- Thomas Miedema chimed into a thread started by Karel Gardas about better parallelizing the GHC build - and hopefully we can get something good out of it. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008749.html
- Austin Seipp made a call for help on working on and improving the GHC homepage, and luckily Sergey Bushnyak answered the call and has helped out! https://mail.haskell.org/pipermail/ghc-devs/2015-April/008762.html
- Ozgun Ataman kicked off a thread about slower compilation times, with some nasty numbers. It's becoming more clear compiler performance should be a priority for 7.12, and we've let some things slip away from us: https://mail.haskell.org/pipermail/ghc-devs/2015-April/008766.html
- A GHC user, Dave, asked the list about some questions with Cross Compilation, as he's attempting to get GHC to work natively inside the Open Embedded build environment. Unfortunately, things haven't been going well so far, and any input from enterprising hackers is appreciated: https://mail.haskell.org/pipermail/ghc-devs/2015-April/008774.html
- Dan Aloni has started a discussion about improving GHC's error messages, spurred by a popular blog post he wrote and posted on Reddit about some Happy/GHC improvements he's made. This is a difficult area (error messages in general are hard) to work on, so thanks to Dan for helping! https://mail.haskell.org/pipermail/ghc-devs/2015-April/008778.html
- Simon Peyton Jones started a discussion about GeneralizedNewtypeDeriving and Safe Haskell, in particular, whatever the current status, our documentation doesn't accurately reflect it! Perhaps someone could help out writing the documentation based on the current status quo? https://mail.haskell.org/pipermail/ghc-devs/2015-April/008783.html
- Tamar Christina started a thread about replacing ghc-split, an old Perl script inside GHC, but he wanted to know: what do we do about a regex replacement? Mikhail Glushenkov spoke up about a similar decision the LLVM developers used: to use the OpenBSD regex implementation. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008785.html
- Alan Zimmerman has posted several questions and threads about the parser and the status of API annotations, which he's been furiously working on now that GHC 7.10 is being used on Hackage. Interested onlookers could learn a thing or two! https://mail.haskell.org/pipermail/ghc-devs/2015-April/008782.html & https://mail.haskell.org/pipermail/ghc-devs/2015-April/008787.html & https://mail.haskell.org/pipermail/ghc-devs/2015-April/008794.html
- Gabor Greif has a question about some seemingly strange behavior regarding the interaction between poly-kinded data types and overlapping instances. Richard sez: this behavior is expected. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008804.html
- Commit de1160be047790afde4ec76de0a81ba3be0c73fa - refactor the story around switch cases (with a code-size improvement)
- Commit 995e8c1c8692b60c907c7d2ccea179d52ca8e69e - drop old integer-gmp-0.5 source code.
- Commit 59f7a7b6091e9c0564f3f370d09398d8c9cd8ad5 - Restore unwind information generation (fixes DWARF generation)
- Commit 9f0f99fd41ff82cc223d3b682703e508efb564d2 - Fix an old bug in the demand analyzer (with some nice compiler performance boosts).
- Commit a7524eaed33324e2155c47d4a705bef1d70a2b5b - Support for multiple signature files in scope (Backpack).
#10222, #10219, #8057, #10226, #10220, #9723, #10230, #10208, #10236, #10213, #10231, #10240, #10243, #10237, #10224, #8811, #10197, #10252, #9958, #10253, #8248, #10207, #10214, #9964, #10194, #10251, #10188, #10257, #10247, #10247, #9160, #10259, #9965, #10265, #10264, #10286, #10282, #10290, #10291, #10300, #9929, #8276, #10218, #10148, #10232, #10274, #10275, #10195, and #10233.