I’ve started to learn elm-lang. It’s seems to be a wonderful but strange language for people like me coming from an imperative (and mostly object oriented) languages background.
While REPLs are great to do exploratory work and understand how things works in a programming language, I’m more used to test driven approach that allows the same exploratory approach with the advantage of persisted files (so I can come back to remember what I did).
Surprisingly I couldn’t found a quick guide to test driven elm programming (probably tests are not as fundamental in elm as in other languages due it’s strong types nature). Anyway, this is my two cents.
Etudes Op. 1: Twelve tone
I’m reading “Notes from the Metalevel: An Introduction to Computer Composition” so, for the test I’ll steal some examples from Chapter 9 that implements some basic twelve-tone and set-theory functions. If you don’t know what is all about, don’t worry, they are very simple functions.
The book it’s used to be online, but I can’t found it now. If you’re interested, you can read an excerpt from the Chapter 9 here but it’s not necessary at all to follow this tutorial.
Project setup
First thing to do is install elm 0.17. This is the latest version at the time of this writing and it brings big changes, starting with elm lang internals and covering elm package names, so it’s important to ensure you have this version installed.
Then, we will use `elm-package` cli to generate the `elm-package.json` automatically and download the dependencies (we’ll use `elm-lang/core` and `elm-community/test` packages):
The `-y` option allows `elm-package` to do it’s work without asking questions, but it’s completely optional.
Write first test
The first function will convert from midi note numbers to pitch class numbers. In test driven programming, we start writing the test, so here is our first `test/TwelveToneTest.elm` attempt:
Nothing very fancy here: just importing ElmTest (from `elm-community/test`), create a function that returns a `suite` of tests and declaring a `main` function that uses `runSuite` to run the tests.
Notice that, unlike Javascript, the expected value goes on the left. This is not important to pass the test, but matters when dealing with test assertion errors.
Run tests
To run the tests we need first to compile to javascript (using `elm-make`) and then run the result with `node`. Let’s make a script:
Elm is known for it’s detailed error messages. Here is our first:
Write the actual code
Let’s write the actual code. The pitch class numbers are just the note numbers without the octave information. Since there are 12 notes per octave, and for each octave the first pitch class is 0 and the last is 11, we just only need to apply module operator:
As you can see, I defined a couple of type aliases, just to be clear about the purpose of the function.
Import the module
Since we are storing the `TwelveTone.elm` source code into the `src/` directory, first we need to change the the `elm-package.json` file so `source-directories` value is `[“src/”]`.
Now we can import the module into the tests:
Now if we run our `run-tests.sh` we get:
Nice!
Coda: Learn some elm
Remember the purpose of this setup is to do some exploratory programming and learn some elm. Let’s try it by implement a couple of functions from the book chapter. First a function to convert from a list of note numbers to a list of pitch class numbers. Test first:
Then the code:
Pretty straightforward. Just remember to import map function from List module.
But the next one is more tricky. We want to normalize the pitch class notes, so always this first note of the list is 0 and the rest are relative to that one. Here’s the test:
Basically, we want to subtract the first element of the list to the rest of the elements. In my first attempt I would write something like this:
The `(\param -> body)` syntax is just an anonymous function. In our case it receives a note and returns the pitch class number. Finally then we map the notes with the anonymous function.
Let’s run our tests:
The problem is that `head` doesn’t return an integer as expected, but a `Maybe(Int)`. Maybe it’s the mechanism elm uses to deal with the equivalent of `null`. If we don’t get an integer is because the list is empty, so we should return an empty list. `case` to the rescue:
This is a very common pattern when dealing with `Maybe`.
The full score
You can get the full source code at github . I hope you find this tutorial useful.
