Fork me on GitHub

Haste 0.5.4, and the features that didn't make it

Version 0.5.4 of the Haste compiler is now available both on Hackage and as binaries from haste-lang.org!

This release does not bring a lot of new exciting features. Apart from slightly improved APIs for working with JSON and JavaScript objects, this release only brings fixes for a few bugs, including a bizarre problem with rational numbers.

Although not present in this release, there are several interesting features coming up in Haste land during this spring and early summer.

What’s cooking?

Template Haskell

One thing that has been requested over and over for Haste is Template Haskell support. It’s clear that not having this is quite annoying to a lot of people, but the implementation is relatively cumbersome and, as with so many things, up until now it has been hard to justify spending the time required to implement it from an academic perspective.

All good things come to those who wait however, and now we finally have an immediate reason here at Chalmers to actually implement TH support. While this is unlikely to happen until after the ICFP ’16 paper deadline in mid-March, it is quite likely that some kind of support will see the light of day during the first half of the year.

Decent pointer support

Poor support for pointers is another of Haste’s major weak points. In the days before Haste.Foreign, it was decided that CString et al should be represented as native JavaScript strings. This seemed like a good idea at the time, making it easier to interoperate with JavaScript than if CString, which is just an alias for Ptr CChar, were actually a full blown emulated pointer. Unfortunately, this makes properly supporting bytestring and other libraries that rely on mucking around in pointer land nigh impossible.

Now that Haste.Foreign has made the vanilla FFI obsolete in a Haste context, this representation is no longer necessary. Consequently, Haste 0.6 will ship with proper pointer emulation, in one stroke erasing a whole class of GHC incompatibilities.

Better handling of JS dependencies

As things stand at the moment, if your application depends on Haste libraries which in turn depend on some JavaScript libraries, you need to manually include every single one of those JS libraries using --with-js when building. This is not only annoying, but flat out stupid. Fortunately, this will very soon be a thing of the past, as support is coming up for baking external dependencies into Haskell libraries, either from the command line or from your project’s cabal file.

A small step for a compiler, but a giant leap for the people who rightfully think manual dependency management is a thing of the past!

Super secret research stuff

In addition to the more mundane library and compiler hacking, we also have some cool research going on here at Chalmers which is going to land in Haste some time later this spring. While I don’t want to spoil the big reveal, or promise features that end up getting cut, let’s just say that both Haste.App users and regular Haste frontend devs are in for a major treat, touching on features as well as performance.

The details, however, are a story for another post or three.