London Haskell User Group: extensible effects

Just did a talk at London Haskell User Group on my brief experiences with extensible effects in Haskell. slides here.

pebble time retrospective

I got a Pebble Time smartwatch, but it turns out I don't wear it much, despite wearing my original (OG) Pebble all the time. I don't even keep it habitually charged.

There isn't one particular reason:

• There are two reasons why I have to keep taking the watch off, something I never had to do with the OG Pebble which I wore 24/7:
  • The charge port is inaccessible while wearing the watch. I didn't realise before hand how much of a problem that would be: I tend to take it off to charge and forget to put it back on.
  • The wristband and/or shape does something weird to my skin that neither the OG pebble nor the 10 wristbands I wear do; especially if the Pebble gets wet (which it otherwise would often, several times a day).
• Application loading is heavily coupled to the phone. I got the Pebble because it has long battery life, but I've found myself in situations where I can't use (e.g.) the compass because my phone has gone flat (which is does by the end of every day). That turns the compass from something I can rely on into a gimmick.
• Not really an ongoing reason, but as I'm in grumble mood, I found the software upgrade experience from OG to Time quite frustrating: I needed a different app from the Pebble app that I already had installed, and it seemed to conflict in a weird way with the existing app.

I have been hoping someone would make a smartstrap to expose charging, but to no avail. Now there's an SDK available for the serial port (which is also the charge point), I might start fixing that problem myself. One day.

Porting todaybot to use extensible-effects

I wrote todaybot (blog, github) a while ago, and it is chugging along just fine, with the occasional bugfix (e.g. due to people writing Swedish).

I've been meaning to play with the Haskell extensible-effects package, so on a lazy Sunday afternoon I started hacking away porting todaybot. My goal was more to get a hands-on feel for extensible-effects rather than actually replace the existing todaybot implementation.

The existing non-effect-based code is pretty rough-and-ready/script-like. It all runs in the IO monad, and state is threaded round manually in a couple of places.

I started by replacing all the IO actions with calls to the (Lift IO) effect. The problems I encountered here were:

• type signatures/type checking errors, with initially impenetrable type errors (reminiscent of what happens when you work with Lens). The constraint based style of effect types gives verbose type errors in a form that I was not used to.
• Some interaction that I haven't understood between type signatures/type inference on effects and on lens types and parsec types(!). I needed to add type signatures on top level lens and parser definitions, which I got using typed holes.
• Handling IO exceptions - I was unsure how exceptions would work so for this first cut I ignored exception handling and let the whole bot die if anything goes wrong.

So now I had a bot with a single effect, Lift IO, with worse error handling than before. I wanted to get this exception handling back in so I wasn't losing functionality. I didn't (and still don't) know of the idiomatic way to handle IO exceptions in (Lift IO).

extensible-effects has exceptions (Exc) already, and I wanted IO exceptions to be handled using those, with the Exc IOError effect. I made a wrapper for lift, called lift' which called an IO action and translated IO errors into Exc IOError exceptions. IO errors then could be handled straightforwardly. Later on it turned out this wasn't enough: code is throwing errors other than IOError which need to be caught (although maybe this is also a bug in the mainline todaybot).

Next, I wanted to start breaking down the use of the IO effect into more focused effects. The one people talk about a lot is logging. There's a Writer effect in extensible-effects already, and logging by writing a string seemed pretty obvious. There's also a Trace effect which is pretty similar. Neither had effect handlers that did what I want: translate the logging effect into IO effects (which in turn would be handled by the IO effect handler). This was pretty straightforward to write, though. There was some messing round with type signatures but I got it worked out in the end.

And the last bit I did before I went to bed was put in a couple of Reader effects: one for configuration (which comes from a YAML file), and one for the authentication bearer token, which is requested during runtime. Writing the handlers for these had a similar feel to writing the handler for logging - a few lines of code inserted into boilerplate, messing round with type errors, raising more questions that I might get round to writing about.

Next I would like to implement effects to handle the last two pieces of IO, which are are access to the current time, and HTTP GET/POST calls; and see if I can use a choice effet instead of mapM_ to iterate.

The (very messy) code is on the exteff branch on github - at the time of writing, up to commit 7ccc0a92....