Hidden Markov Models for Natural Language Tagging, in Haskell

I became intrigued in Hidden Markov Models after reading Kurzweil, who claims they can be used to model the thinking process in the brain. There is much debate about that, but these are interesting AI structures. This page I think has a good introduction.

I was working though the (partial) online book on Natural Language Processing with Haskell, and thought of combining the two. I used Mike Izbicki's hmm library for a one order Hidden Markov Model implementation. Once I initialized the model properly using the training data, I got around 91% accuracy on tagging, which is on par with the rules based approach presented in the nlpwp book.

I used the strategy outline in this paper to deal with unknown words (words in the test set not met in the training set): replace these words with a token that is also used for low frequency words in the training set. So far I've used only one token but I suppose being a bit more fined grained (to distinguish words starting with a capital letter, currency amounts, numbers) will improve results.

Performance is not very good even with some parallelism, so I think I need to spend more time on it, but it's definitely encouraging. It'll be a little bit of time till I have a thinking brain, though, but there is hope!

Beginning Haskell: the Book!

It's my pleasure to relay the news of the publication of a new Haskell book, Beginning Haskell. It's written by one of EclipseFP contributors, Alejandro, and I've had the pleasure to be a technical reviewer of the book. I learned a lot, so I can heartily recommend it! It takes the reader from the very basics of functional programming to some intermediate and advanced Haskell techniques. Alejandro of course talks about it better than me.

Happy Haskell Reading! Thanks Alejandro for the great work!

Haskell Worksheet in EclipseFP 2.6

A sneak preview of the worksheet functionality in the upcoming EclipseFP release. I have a Haskell module with a few functions, and the worksheet displays some results using different rendering modes:

• Simple text: shows the result of the expression as GHCi would
• HTML/SVG: renders HTML markup and SVG images in a SWT Browser element. In the screenshot there's Blaze HTML and Diagrams SVG
• JSON: display JSON objects and arrays in a tree

We use BuildWrapper and the GHC API to execute the expressions every time the file is saved. The expressions are persistent and hence survive restarting Eclipse.

I don't know when EclipseFP 2.6 will be released, but you can of course get the current code from github.

Cabal sandbox support in EclipseFP 2.6

I seem to have managed to free myself a bit of time, which means I can work a bit on EclipseFP 2.6.  I've added support for cabal sandboxes, so you'll be able to use sandboxing with cabal 1.18 in pretty much the same way cabal-dev was supported. You can have a per project or per workspace sandbox, and the fact that add-source is dynamic simplifies the internal code somehow. Cabal-dev is still supported.

A nice side effect of supporting Cabal 1.18 (thanks again to dynamic-cabal) is that we can use a sandbox to install the executables we need, like buildwrapper and scion-browser. Up to now, if you hadn't installed them, you'd get a dialog box asking you if you wanted to. Users have complained that this was an unnecessary step, but I didn't want to install executables with many dependencies into the user's package database without a notice. Now, executables get installed into a specific sandbox, so the install may be a bit longer if you already had some dependencies, but we don't mess up anything on your system.
The only issue is that inside a cabal sandbox, all packages need to be coherent: you cannot have two different versions of the same library. This shouldn't normally be an issue, but it is at the moment, because we try to install HLint and SourceGraph, that both require a different version of haskell-src-exts. I have sent a patch to Ivan Lazar Miljenovic so that SourceGraph can support the latest version of haskell-src-exts so hopefully this will be sorted by the time EclipseFP 2.6 hit the metaphorical shelves.

So hopefully EclipseFP 2.6 will be easier to install and will take advantage of the latest Cabal functionality!

Dynamic-cabal to solve dependency hell in BuildWrapper

As I've explained in several places, we have an issue in BuildWrapper (the underlying Haskell program for the EclipseFP plugins): BuildWrapper depends on both the GHC API and the Cabal API. Since GHC itself has a dependency on Cabal, once you've installed GHC, BuildWrapper can only use the same version of the Cabal API that was used by that GHC. Moreover, some Cabal files (setup-config in the dist directory for example) are cabal version dependent (since they only serialize Haskell structures, this is for safety). The net result is that if you install a newer version of Cabal and cabal-install, BuildWrapper still uses the old version, and hence the Cabal library BuildWrapper uses and the cabal-install executable have different versions, and hell breaks loose.

I have looked at solving the issue in GHC itself: GHC does not need to have a dependency to the Cabal API. I had started investigating with help from GHC devs, but it was end of October, and I had understood that GHC 7.8 was to be released in November, so there was no time to do such a change. So I thought I would wait for the next release. But it's now end of December, and GHC 7.8 still hasn't been released. So should we have to wait another year to solve that issue? Gasp!

But then, out of the blue, help came! Benno Fünfstück released dynamic-cabal, with the promise that it would solve exactly this issue! I actually should have had that idea myself, but hey... Basically, dynamic-cabal provides simpler structures than the full Cabal API, and extracts them from the Cabal API via dynamic code generation. The code is generated and ran dynamically using the GHC API. Since the running code itself doesn't depend on GHC, it can use the latest version of the Cabal library, and hence read the setup-config file properly!

I have now rewritten parts of BuildWrapper to use dynamic-cabal, and I only had to add minor enhancements to dynamic-cabal. I have upgraded my own cabal-install to 1.18 and everything works (my GHC still uses Cabal 1.16)!! I'm not releasing that version yet because it will provide some new features for EclipseFP 2.6, but if really you want to give it a try just build it from Github.

So my thanks go to Benno! A big hurdle has been cleared on EclipseFP's path to world domination!

EclipseFP 2.5.6 released

It's my pleasure to announce a new version of the Eclipse plugins for Haskell development, version 2.5.6! This is a minor, bug fixing release. The release notes can be found here.

To install, just point Eclipse to the update site: http://eclipsefp.sf.net/updates.

I expect that the next version will be a 2.6 with more features, as hopefully I'll have more free time.

Happy Haskell Hacking!

Reactive-banana-SDL on Hackage!

I've uploaded to Hackage the reactive-banana-sdl library. This library was developed by R. Kyle Murphy(orclev), and I've just added a couple of functions and some documentation in the code. Orclev didn't want to maintain it anymore so I've taken the maintainer role, but I'm certainly not a FRP expert (in fact I started to use the library to learn about FRP), so be gentle...

I have a little typing game called TypeClass, which uses the library. You can have a look at the code, it may help you get started.

There's not that much there, but hopefully this can be of use to some people, and let me know what goodies we could add!

Happy Reactive SDL Hacking!

Acme editor for Haskell development?

 A post on reddit made me discover the Oberon system and the Acme editor, that drew inspiration from it. There is a cool video on YouTube of the Acme editor in action. The concept that "everything is Text" and "every bit of text can be an executable action" looks really powerful, even if it looks like it would take a bit of practice to get used to the mouse chording and the intensive usage of the three mouse buttons.

Working with an IDE that's quite heavy (understatement of the year), I'm certainly drawn to that simplicity and power much more than to other editors like Emacs and Vi, where it seems you have to remember an near-infinite list of arcane key combinations to be productive.

So I'm wondering, are there people out there using Acme or Oberon or Plan 9 for Haskell development? How do you find it? What good ideas could be applicable to other environments? I'm always looking out for ways to improve EclipseFP and Haskell development tools in general, is this a path worth exploring?
I've seen that blog entry, from somebody apparently using Erlang, and I noticed the following: Other sacrifices are syntax highlighting, automatic indentation, specific language support. Is that true? Isn't there a way to add syntax highlighting in Acme? And I suppose the specific language support you get by exposing your tool via the Acme system for text commands...

Happy Haskell Hacking, on Acme or not!

EclipseFP 2.5.5 released!

It is my pleasure to announce a new release of EclipseFP, version 2.5.5. EclipseFP are Eclipse plugins for Haskell development. This is mainly a bug fix release with only small enhancements, so I recommend everybody upgrade (from the update site http://eclipsefp.sf.net/updates).
The release notes can be found here.

I'm hoping that the next release will be a major one, with big enhancements. So I'll gladly have contributors if people want to join the fun!

Happy Haskell Hacking!

EclipseFP: laundry list for 2.6

I seem to have a bit more free time these days to work on EclipseFP, so I was thinking about what we should try to add in the next major release. In no particular order:

• Sandboxing via Cabal 1.18 support and not only cabal-dev. Maybe also using cabal repl could replace some code in the GHCi launch configuration management.
• HSpec 
• Cabal bench
• An Haskell worksheet similar to the Scala worksheet. This would allow a better integration with the UI than running a GHCi launch, and would be able to persist test expressions over reloads and even Eclipse restarts. This would help people to play around with their code and see the results straight away. We could add things like time of execution, history of timings so you could check if you're improving the performance, pluggable graphical representations, save as unit test (make a unit test that checks that the given expression always give the current result)... Note that buildwrapper already has code to perform evaluations of expressions using the GHC API, but this is not used yet by the Eclipse front-end.
• Integrate HaRe (into buildwrapper since it now uses the GHC API?) to provide more refactorings.
• See if new versions of tools we depend on, like haskell-src-exts, can do more things for us or allow us to get rid of some of our code to rely on theirs (yeah!)

Let me know if you have some great idea that's not on the list, or if any of these are of special interest to you. I know there some other requests that people have made that I haven't implemented yet, so you can also check the issue list and comment on those you'd like to see treated with higher priority.

If you feel the urge to fork the github repository and start working on something, please don't refrain, I'll be happy to get more contributors!

EclipseFP: package version bounds in dependencies

Coming in EclipseFP 2.5.5, the cabal editor lets you specify what policy you want to use in respect to versin bounds when adding a dependency to a package, instead of just referencing the package without any constraints, or having to type them by hand:

You have four options:

• None: as before, doesn't generate any bound
• Current major version: will restrict to the major version of the package you currently have
• Current major version from current minor: the minor version of the package you currently have is going to be the lowest version allowed, up to the next major version. This is the default, since it assumes the current version you have is the one you're testing against
• Current minor version: only use the minor version of the package you currently have

The text field shows you the actual values that get generated. This field is now read-only since you can first select a package then change the version restriction options. If you want to enter manually the version bounds, you can still do that on the main page where all the current dependencies are listed.

I hope it will let you conform to the Package Versioning Policy and provide reasonable dependency bounds on your libraries.

No date on the 2.5.5 release yet, there's a couple of things I'd like to do first. The Github version should be usable if any of you want to live on the edge (and perform some valuable testing!).

EclipseFP 2.5.4 released

Hello folks, a new bug-fixing release of EclipseFP. Nothing major, mainly fixed a big bug that caused the plugin to randomly not start properly in Kepler, and few little enhancements to make life easier. The full release notes have all the details.

I'm also pleased to announce a new contributor, Maik Riechert, who contributed a hyperlink detector so that hyperlinks in source files can be followed.

As usual, just update from within Eclipse using update site http://eclipsefp.sf.net/updates.

Happy Haskell Hacking!

EclipseFP 2.5.3 released

Hello, I've just released a new version of EclipseFP, 2.5.3. This is a minor release for bug fixes, general stability and hopefully better performance.

You can find the release notes here: https://raw.github.com/JPMoresmau/eclipsefp/master/docs/releasenotes/net.sf.eclipsefp.haskell_2.5.3.txt.

I don't have a lot of time for EclipseFP at the moment, being busy on other projects, but I'm well aware that there are a few enhancements that people have asked for in the queue. I'll try to address these later on, and of course I'll happily accept pull request on https://github.com/JPMoresmau/eclipsefp.

As usual install or update by pointing your Eclipse to http://eclipsefp.sf.net/updates.

Happy Haskell Hacking!

Eclipse Hate and Haskell IDEs

A few weeks ago I was reading the comments about the release of Android Studio on reddit. I was a bit shocked by all the Eclipse hate. But hey, I suppose I use Eclipse and not IntelliJ, so I don't know what I'm missing and how great it would be to work on IDEA. But then I was surprised to see that there has been no release of ideah, the Haskell plug-in for IDEA, for a year and a half. How come there isn't more momentum if IntelliJ is such a great IDE to build on and work with?

Maybe we're just suffering from too much dispersion in the Haskell IDE space. We have plug-ins for the major IDEs, but none of them can probably called great (I know, some people positively hate EclipseFP, but for my defence I'll say I get much more bug reports and feature requests than pull requests, I probably need a course on "building a passionate programming community around your open source project"). They however have the massive advantage of being able to reuse a wealth of existing code (I can use the Eclipse Git plugin to work with Github, I don't need somebody to write the Haskell version). An IDE in Haskell like Leksah or something built on top of Yi would be amazing to showcase that you can do real applications in Haskell (since you still get people saying that Haskell is only for toying with), but then you need to build everything, which requires people (see note above on building a community). Then we have web based editors like the offering from FPComplete, but for developers to use them on real projects we need to think on how to package a web based interface and what it means for a development work-flow: I'm not sure developers would embrace developing using a browser. Of course we have plug-ins for the Unixy editors, emacs and vim, but if we want to open up Haskell to non hackers, maybe we need something more...

So can we continue like that and hope to have a few decent environments? Or shall we all agree on a direction and unite to provide the one true development environment for Haskell? Sometimes people say "Haskell is so different and advanced as a programming language, it needs a new type of editor/IDE". I don't disagree with it, but who has the vision of what the Haskell IDE should be?

Moving from Windows 8 to Ubuntu (I'm a Haskell on Windows developer no more!)

I bought myself a new laptop the other day, and while I'm happy with it, it came with Windows 8. This wasn't an issue per se, once I looked up on the internet how to find the "shut down" button... Sure, the gestures are a bit annoying when you don't have a touch screen, but I could live with that.

But then I started running into familiar issues again, as I tried to set all the Haskell libraries I needed for a project: libraries not working on Windows, MinGW/MSYS/Cygwin hell, etc... I just couldn't take it anymore. So I guess this is an admission of defeat that when you need work done quickly using a significant number of Haskell libraries, you need a Unix based OS.

So I decided to dual boot the computer with Ubuntu. I don' really know why I chose Ubuntu, from looking around it looked like it was both stable and developer friendly.

I was first pleased to see that Windows would give me tools to resize my main partition. I remember a time where you had to use third party software to to do that!

I burned a DVD with the 12.10 image (I see 13.04 is out, I'll have to upgrade some day I suppose), and went with the Linux Secure install. It didn't recognize that I had a Windows install, so I configured my partitions and tried to understand what the messages about the boot loader meant. But when I restarted, I went straight to Windows as if Ubuntu didn't exist. So I restarted using the DVD, and launched the Boot Repair utility. At the end it told me that I had to change something in the UEFI options of the computer. I went in there and sure enough there was an entry for Ubuntu. Once I selected that, I could now see the dual boot screen, giving me the choice between Ubuntu and Windows, and both work! Success!

After that, not much sweat to report. I quickly appreciated apt-get, as opposed to the various downloads+install procedures you get for windows software. Sure, at the time I installed it, Eclipse was still 3.8 and not 4.2, but I'm not going to complain.

Ho, and the library I needed that I couldn't get to work on Windows? Installed like a charm.

I'm now a Ubuntu Haskell developer, and I don't regret it.

EclipseFP 2.5.2 released

I'm happy to announce a new bug-fixing release of EclipseFP. You can see the release notes here.
A few issues around the use of cabal-dev were found, as expected, and fixed, and a couple of little feature requests have been put in.
Hope this helps! As usual, just upgrade Eclipse using the update site http://eclipsefp.sf.net/updates.

Happy Haskell Hacking!

EclipseFP 2.5.1 released

Quickly on the heels of 2.5.0 I'm releasing 2.5.1. This is mainly to fix an issue that caused the Editor->Syntax preference page to not open.
This release also add the possibility to change the font and colors of the tooltip in the editor (under Preferences->General->Appearance->Colors and Fonts, Haskell). It also searches for executables under $HOME/Library/Haskell/bin, which seems to be a path for executables on MacOS.
Also, some UI enhancements for Eclipse 4.2. The full release notes are here.

To upgrade just point your Eclipse to http://eclipsefp.sf.net/updates. Report any issue to the SourceForge forum.

Happy Haskell Hacking

EclipseFP 2.5.0 released

It's my pleasure to announce another release of EclipseFP, the Eclipse plugins for Haskell development.

In this feature, I've added support for cabal-dev, as demonstrated in this video.
I also have added a "organize imports" function on an opened source file. This cleans the import lists by only importing what's really used and formatting it in a manner similar to what stylish-haskell does.

I have also tried to improve the performance of the editor, and fixed all bugs we were made aware of. Syntax highlighting can now highlight more tokens in different colors (non alphanumeric symbols, different types of comment).

Full release notes can be seen here.

As usual, to upgrade just point your Eclipse to http://eclipsefp.sf.net/updates. Report any issue to the SourceForge forum.

Happy Haskell Hacking!

Porting my typeclass game to reactive-banana-sdl

Some time ago I wrote a tiny game called TypeClass, just to experiment with the SDL bindings for Haskell. I was always curious to learn more about FRP, but never really knew where to start. So I just decided to change TypeClass to use reactive-banana, since it looked like a nice library with a dedicated author. And there are SDL bindings too!
It took a bit efforts since I didn't find any sample in reactive-banana-sdl, but I finally got it working. The game is exactly the same from the outside, so it still not that exciting. But I feel I've made progress in understanding events and behaviors and how it all fits together.

I've put the game on github, so anybody else interested in using reactive-banana with SDL can at least have a sample. It requires my own version of reactive-banana.

Happy Haskell Hacking!

EclipseFP + cabal-dev

Some of EclipseFP users had a dream: use cabal-dev sandboxing capabilities to manage their Haskell projects in EclipseFP.  Well, we're getting there. I've uploaded a video of the current state of EclipseFP and cabal-dev integration. The workflow is as follows:
- Fill in the cabal-dev location in the preferences page. Once this is filled, all your Haskell packages will be sandboxed
- Create projects as you would normally
- In the Cabal editor, local projects will now be available as dependencies. When you select a project as a dependency, a project reference is created by Eclipse. The dependent project is then installed in the current project sandbox
- Building, autocomplete, GHCi sessions, etc. will use the project sandbox

Under the scenes, we're only using cabal-dev install --sandbox=.... Thanks Rogan for the help!

This will be part of EclipseFP 2.5.0. I urge adventurous hackers to get the current version from github and start testing!