Long time Haste users may be familiar with a rather horrifying bug on OSX where haste-cabal would fail due to Apple’s somewhat overzealous “System Integrity Protection”. Well, no more! As of version 0.5.5.1, Haste is back in business on your Mac.

As usual, the binaries are available from the downloads page, and the source from our GitHub repository.

As the talks from this year’s Haskell Symposium hit YouTube today, this might be a good time for a post about the Aplite EDSL for speeding up the most computationally intensive parts of your Haste programs. Of course, you could just watch the talk instead, or read the paper if you want a more in-depth treatment.

Read more...

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

This release fixes a few embarrassing bugs, and automatically installs QuickCheck during the boot process. Of course, if you downloaded the pre-built binaries, QuickCheck is already included.

Read more...

A quick heads-up: version 0.4 of ghc-simple, Haste’s interface to GHC, is now out. This means that Haste moves one step closer to supporting GHC 8.0.

Any bugs found in this release should be reported to the package’s bug tracker.

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

Being a point release, 0.5.4.1 doesn’t bring any new features whatsoever. It does, however, bring a few small compatibility enhancements, which may have a disproportionately large impact.

Read more...

Today, Haste reached 1,000 stars on GitHub. A small star for one person, but a large, nicely round number for Haste. To mark the occasion, here’s a bunch of random Haste-related numbers.

• 1,000 stars on GitHub, making Haste the 19th most starred Haskell project
• 38 contributors, with a total of 1,631 commits
• 31 official releases starting with version 0.2 in July 2013
• Est. > 15,000 downloads
• Used in three courses at Chalmers, plus two BSc and two MSc theses
• 6,884 lines of Haskell (ghc-simple + compiler)
• Plus an additional 6,302 lines of Haskell (haste-lib)
• And 7,495 lines of JavaScript

Wow, so code, much downloads!

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.

Read more...

While the trick described in Haste and cabal files works well when you want to build the same Cabal project using Haste and GHC, it does nothing to alleviate the problem of dependency bleed in Haste.Apps: server side dependencies creeping into the client and vice versa. While this is not necessarily a big deal, investing some time upfront in separating client and server dependencies from each other can yield nice returns in the form of shorter compile times and less wasted disk space.

The trick described in this post uses the C preprocessor Haskell extension to conditionally compile your Haste.Apps in such a way that dependency bleed is avoided, and is quite closely related to the techniques used to implement Haste.App itself.

Read more...

When creating a Haskell project using Haste, it’s not all that uncommon to want that project – or at least parts of it – to be buildable with vanilla GHC as well. Considering that Haste.App, which is shipped with the standard Haste distribution, more or less requires this functionality to work at all, this is quite a reasonable requirement.

Since Cabal (or stack if you want to be all cool and up to date and stuff) is the build system for Haskell projects, you probably have a .cabal file for your project:

name:                myapp
version:             0.1.0.0
author:              Jane Doe
maintainer:          janedoe@example.com
build-type:          Simple
cabal-version:       >=1.10

executable myapp
  main-is:           Main.hs
  build-depends:
    base      >= 4.8 && < 4.9,
    haste-lib >= 0.5 && < 0.6
  default-language:  Haskell2010

Your application builds just fine when using haste-cabal, but when you try to build it using vanilla cabal, you get the following message:

Resolving dependencies...
Configuring myapp-0.1.0.0...
cabal: At least the following dependencies are missing:
haste-lib ==0.5.*

That’s not good! What really went wrong here, and how can we fix it?

Read more...

Writing applications using Haste.App has always required a certain amount of manual labour. Installing and configuring a web server to serve the client part is a bit annoying when you’re going to be running a separate server process anyway. Similarly, rebuilding your application with a new configuration whenever you want to deploy it to another host, since your client part will otherwise try to connect to the wrong server, does not exactly feel very modern. It would be so much more convenient if we could compile our application once and have it Just Work(tm) wherever we deploy it.

Fortunately, these problems are not inherent to the Haste.App programming model. As a proof of concept, I’ve hacked up a small tool called haste-standalone, which lets you write applications using Haste.App that

• don’t require a web server;
• don’t require any static configuration; and optionally
• serves any required static files, such as HTML or images, on its own.

The best part? It only requires you to change a single line of code in your application!

Read more...