Ope’s blog

Ope meet Haskell

2020-05-10T11:00:25+00:00

There are two main styles of programming. Imperative Programming and Declarative Programming. Programs written in the imperative style describe the exact steps the computer should take i.e the “how” while programs written in the declarative style describe the desired result we want i.e the “what”.

Functional programming is a declarative style of programming. It is called functional programming because programs written in the functional style are made up of functions which are combined in different ways to form the main program.

Different languages support different styles of programming. To learn functional programming, I had to learn a language that supports the functional style very well - a functional language. There are a number of functional languages e.g F#, Scala, Haskell, Elm. I decided to learn Haskell because it is reputed to be the “purest” of the functional languages.

Haskell

Haskell is a typeful, lazily-evaluated functional language.

typeful - Haskell is statically typed. This means that every expression in Haskell has a type known and checked at compile time. However, unlike some statically typed languages, you don’t need to add types to every expression. Haskell can infer the type of an expression based on how it is used.

lazily-evaluated - values in Haskell are not evaluated until they are needed. This means that if you have a function that accepts two arguments and returns the first, the second argument will not be evaluated. Most programming languages use eager evaluation instead ie. the arguments of a function are evaluated before the function body.

functional - function are the primary means of abstraction in Haskell. They are mathematical functions not procedures i.e given the same input, a function will always return the same output without any side-effects. They can be passed in as arguments to functions, returned from functions and stored in data structures just like any other value.

How I went about learning Haskell

I started off reading Learning you a Haskell for great good. I didn’t enjoy it because it didn’t teach concepts, it just had a lot of Haskell code and it didn’t have exercises either. In my search for another book, I found this talk by Chris Allen which I recommend. Instead of picking up his book, I picked up A Gentle introduction to Haskell.

A Gentle Introduction to Haskell is the official language tutorial for Haskell 98 - the version of Haskell defined in 1998 - so it is dated but it was exactly what I was looking for. It explained Haskell concept by concept and it is also short enough that it didn’t feel daunting to complete. I also skimmed through a book recommended by the tutorial - Introduction to Functional Programming by Richard Bird. I enjoyed this book because it taught the functional style very well. It also introduced me to the technique of using mathematical laws to derive more efficient equivalent functions.

After going through these three materials, I could write basic Haskell programs but I could tell I still had major gaps in my knowledge. To fix this, I will be going through Programming in Haskell by Graham Hutton.

I also picked up different papers that explained Monads and Lambda calculus. You can find links to them in the resources section at the bottom of this post.

If I had to start all over, I would probably learn from Haskell from first principles. I didn’t because I thought the book was expensive and too big (I like reading books from cover to cover and it looked daunting to go through over a thousand pages). I like that the authors tested it with beginners to make sure it was effective and my skimming through it makes me believe it is quite good.

Haskell concepts that stood out for me

Learning Haskell exposed me to some of new concepts. I will introduce some of them briefly.

Pattern matching - pattern matching is a way of deconstructing a complex objects into its components. Pattern matching is often used when defining a function with a set of equations. The resulting function definition is very easy to read and if recursive, the base cases stand out. e.g

length :: [a] -> Int
-- this is one equation for length for the case of the empty list
length [] = 0  -- match empty list, length is zero
-- this is one equation for length for the case of list with more than one item
length (x:xs) = 1 + length xs -- match head:rest

Parametric Polymorphism - This means you can write functions that operate over a type that is parametrized. For example, the length function above makes use of parametric polymorphism since it works with a list that contain values of different types. e.g [Int], [Char], [Bool]
Ad-hoc polymorphism via Type classes - Haskell also suports ad-hoc polymorphism i.e a function with different implementations based on the type of value it is called with. To use ad-hoc polymorphism, you need to add a context to the type declaration of your function. In the function below, you can only call qsort with a list that contains values of type a if a belongs to the Ord type class. For a to belong to the Ord type class, it needs to have an instance declaration and implement the functions defined in the Ord type class.
```
-- instances of the Ord typeclass have the ordering operators defined.
-- i.e ==, /= , <= etc
-- Ord a is a context
qsort :: Ord a => [a] => [a]
qsort [] = []
qsort (x:rest) = [v | v <- rest, v <= x] ++ [x] ++ [v | v <- rest, v > x]
```

Algebraic Data types - Algebraic Data types are a way of creating more complex data types from simpler ones using either Sum types or Product types. For example,

-- a Maybe type is either Nothing or Just 5 - this is a sum type
data Maybe a = Nothing | Just a
-- a pair contains two types - this is a product type
data Pair a b = Pair a b

Monadic I/O - Haskell programs are made up of pure functions with no side-effects. This is a problem because without side-effects a program cannot perform useful work. To solve this problem, Haskell uses the IO monad. A monad is a type constructor plus two functions return (aka unit) and bind(aka >>=). Values with type IO a are also called actions. Actions can be sequenced together to form a bigger action. The rules for sequencing actions is based on the monadic laws. return takes an ordinary value and wraps it in IO. bind combines two IO actions so that result of one is the input of the other, the result of bind is IO a.

These explanations are very brief but they should give you an idea of what Haskell looks like. You can find a relatively concise introduction to Haskell here

First impressions

The good

Pattern matching + writing a function as a set of equations is awesome
Type inference is awesome.
I love that you can identify a pure function from it’s type signature and that you have to separate pure functions from impure functions.

The not so good

Compiler messages can be scary and tooling is a work in progress. For example, I called fold but flipped the position of two arguments and I got a long stack trace that was not useful in locating the error. To prevent errors like this, I looked for Haskell extensions that would integrate with my editor. I found the HIE extension but I couldn’t get it to work locally until I used it with a devcontainer but then I couldn’t install stack in the devcontainer. 🤦
Haskell has a steep learning curve. There is a lot to learn even if you are an experienced programmer but with no experience with a similar language.

Conclusion

So was this worthwhile?

ABSOLUTELY!

I learned a lot. The best part is that learning new concepts forced me to think deeply about what I already knew. I have more things to compare and contrast. e.g Lazy evaluation vs. eager evaluation.

I recommend Haskell if you are looking for intellectual stimulation and ideas that will serve you well even if you keep programming in whatever language you are using right now.

Resources

Thanks Olamilekan and Lynda for proof reading :)

How I wrote a JSON parser in Go - Part 5 - Summary

2019-12-21T13:49:25+00:00

So what were the main lessons I learned from this?

Software engineering lessons

I feel like I have a solid grasp on how to write libraries. My process is: -

start by designing the public interface
write a MVP with the core features
refactor your code - if there are missing abstractions add them, if you took shortcuts fix them
add more features and refactor again if necessary
optimize space and time I also learned that a domain driven design mindset is very helpful. By this I mean in particular writing code that mirrors the domain(or problem space) closely. In this case, the domain is the JSON specification and my code corresponds to it as much as possible. I used the same names and if you check json.org, even the structure is similar to the diagrams explaining the specification. This is very important.

Takeaways for when next I do a learning project like this

Done is better than perfect. It took me too long to write about this project. I should have focused on getting it done and moving on.
I learned that next time I have a project like this, I need to set a time limit so it doesn’t drag on forever. It is hard to get back to things when I have context switched to other things.
I need to make sure I incorporate writing about the project into my process of working on it. My current idea for enforcing this, is to make sure that when I make a PR in the description I write the blog post.

How I wrote a JSON parser in Go - Part 4 - Optimization

2019-12-20T14:49:25+00:00

In the last post, I talked about how I implemented all the features in the JSON specification. That’s nice but I was curious to see how my implementation compared performance wise with the existing standard library implementation.

One of the clues that I had a performance problem was when I tried to compare the time it takes to load two huge strings when my code was at this state. My implementation took forever to load it and I had no idea why. After a bit of guessing, I still couldn’t figure it out so I wrote benchmarks. Go has builtin support for benchmarks. A benchmark looks like this.

func BenchmarkMyMapOfString(b *testing.B) {
	b.ReportAllocs()
	str, err := ioutil.ReadFile("testdata/map_of_string.json")
	if err != nil {
		panic(err)
	}
	Load(str)
}

I wrote the benchmarks so I could use them to test the performance of different features - string parsing, array parsing and object parsing. It turns out my string parsing was taking forever. I looked at the standard library’s implementation to figure out why and after a while of looking I noticed the major difference was that they were using the strconv.Unquote function. I used Unquote to parse strings and suddenly my performance was comparable with the standard libraries implementation. This also made me realise that my model for how Go works wasn’t complete. It appears that if you are going to be doing something like this

s := make([]rune, 0)
for i := range(1000){
    s = append(s, rune('a'))
}

it is going to be slow because allocations take time. I certainly wasn’t thinking about that before. Once this was fixed, the performance of the two implementations was comparable. My job was done! You can find the code here

Json parser ✅

In the last post, I will be summarising what I learned from this project.

Stay tuned!

How I wrote a JSON parser in Go - Part 3 - More features

2019-12-20T13:49:25+00:00

In the previous post, I wrote about how I added the iterator abstraction. In this one, I will be discussing how I added new features.

Parsing null, true and false

The first thing I noticed was that to parse null, true and false, I could use the same function which I called loadKeyword. loadKeyword accepts an iterator, the value to parse and the object that should be returned. The function looks like this

func loadKeyword(iter *iterator, keyword string, value interface{}) interface{} {
	for _, val := range keyword {
		if rune(iter.getCurrent()) != val {
			panic(fmt.Sprintf("There was an error while reading in %s", keyword))
		}
		iter.advance()
	}
	return value
}

and these lines were added to the load function.

case iter.getCurrent() == 'n':
    return loadKeyword(iter, "null", nil)
case iter.getCurrent() == 't':
    return loadKeyword(iter, "true", true)
case iter.getCurrent() == 'f':
    return loadKeyword(iter, "false", false)

This means we can now parse these strings correctly

obj := Load("{"k1": true,"k2": false,"k3": null}")
obj := Load("true")
obj := Load("false")
obj := Load("null")

Parsing numbers

I decided to support parsing integers first. This just required writing an isNumber function and a loadNumber function. The code looks like this

func isNumber(iter *iterator) bool {
	switch iter.getCurrent() {
	case '1', '2', '3', '4', '5', '6', '7', '8', '9':
		return true
	}
	return false
}

func loadNumber(iter *iterator) interface{} {
	num := 0
	for !iter.isEnd() && unicode.IsDigit(rune(iter.getCurrent())) {
		num *= 10
		val, _ := strconv.ParseInt(string(iter.getCurrent()), 10, 64)
		num += int(val)
		iter.advance()
	}
	return num
}

For negative numbers, I just checked for the sign at the beginning and then proceeded with parsing the rest of the number and then multiplying by the sign at the end. For decimals, I added logic for checking for ‘.’ and parsing the fractional part. For exponents, I added logic for checking of ‘e’ or ‘E’ and parsing the exponent. The code for this can be found here.

That’s all of the features in the JSON specification. 😄.

Notice that to add these new features I didn’t have to change already working code and I had tests to prove that it all works like expected.

That’s the all, right?

Wrong.

The next step when writing a library is to benchmark it and then optimise. I was curious how my code compared with the standard libraries implementation. This step is the subject of the next blog post

Stay tuned!

How I wrote a JSON parser in Go - Part 2 - Refactoring

2019-11-19T13:49:25+00:00

In the previous post, I talked about how I wrote a minimal viable parser i.e one that could parse in strings, arrays and objects. It works as advertised but I noticed there were a couple of things I could do to improve on the code before I added more features from the JSON specification.

Abstractions wanted

So one of the things I noticed was that almost all functions have this input signature - (s string, current int). This was a clue that there was a missing abstraction.

What does s and current represent?

s is the entire string to be parsed and current is the next index of that string that has not yet been parsed. Conceptually, they are related. For example, it doesn’t make sense for current to be a negative number since it represents a position in a string. It also doesn’t make sense for it to be greater than the length of s either. So what is the right abstraction for both variables?

My first thought was to create a class called scanner that will encapsulate these two variables. This is similar to the approach used in the standard library implementation (I skimmed through it briefly after I was done with the MVP)

It looks like this

type Scanner struct{
    s string
    current int
}

func (s *Scanner) consumeWhiteSpace(){

}

func (s *Scanner) isObjectStart(){

}

func (s *scanner) isObjectEnd(){

}

func (s *scanner) loadObject(){

}
//... other missing methods

But I wasn’t convinced this was the best solution. It would mean that the parsing function would just be calling methods on an instance of this class and my design sense felt it was doing too much. It knows about when the current index is at a mapping start or end (i.e the next thing to be read is a ‘{‘ or ‘}’),. It knows how to return object created from the string and index etc.

After some time thinking, it occurred to me that the right solution was to model s and current as an iterator. The responsibility of an iterator is to support iterating over the items of a particular object. The code for the iterator looks like this.

package json


type iterator struct{
	s string
	offset int
}

func (iter *iterator) getCurrent() byte {
	return iter.s[iter.offset]
}

func (iter *iterator) advance() {
	iter.offset++
}

func (iter *iterator) isEnd() bool {
	return iter.offset >= len(iter.s)
}

The iterator is very lightweight and focused. The invariant that offset shouldn’t be greater than the length of s isn’t enforced here but it is added later and it was easy to add. I rewrote all the functions that previously accepted (s string, current int) to accept (iter *iterator) instead and all my tests still passed!

This is the state at this commit.

In the next post I will talk about how I added support for the other features in the JSON specification. This will show that my approach still works when I implement more features - without having to change what currently works. This is a desirable quality when writing code.

How I wrote a JSON parser in Go - Part 1 - MVP

2019-10-13T13:49:25+00:00

Hey! Welcome to my first blog post in a series about how I wrote a JSON parser. This series assumes the reader has some basic programming experience. In this post, I will be talking about how I wrote the MVP of the parser.

In the posts in this series, I will reconstruct the process through which I wrote the parser. It’s not a perfect reconstruction because although I have a commit history and some original notes, some time has passed between writing the code and writing these posts. Despite this, I believe it is useful to document not just the end result(i.e working code) but the process that produced it. (my thoughts, rationale for decisions, order in which I wrote that code etc.)

That’s the main takeway I want my readers to leave with. My major reason for writing this was to deliberately practise software engineering; by this I mean, to try out software engineering ideas (my ideas and ideas I have come across) in a project and take note of what works and what doesn’t. The other reasons were to practise writing Go and practise writing.

JSON

JSON stands for JavaScript Object Notation. It is a data-interchange format that supports 6 data types.

string - starts with a " and ends with a " e.g "string", "key"
number - represents a number e.g 2.4, 2.0, 12
boolean - this has only two possible values - true and false
null - it is represented by null
array - this contains values of other json types in order e.g ["abc", 123, true]
object - this contains key and value pairs (the key must be a string and a value can be any type supported by json) e.g `{“key”: 123, “k2”: “string”}

for more information, you can check here. It has lovely diagrams and explains the entire JSON specification very well.

MVP

For the MVP, I decided to focus on a supporting a subset of JSON grammar. I picked this subset based on what I thought would be a good foundation upon which I could add more features without having to change code that already works. Those features were

being able to parse strings without escapes
being able to parse arrays
being able to parse objects

Parsing

The first thing I did was to design the public interface of the parser. This interface has just one function - Load. I called this Load because I was influenced by python’s json library’s naming (I didn’t realise it at the time). Other names I could have used are Parser and Unmarshaller but to be honest I just went with what popped in my head first. (I eventually changed this name). The other design decision was to decide what the function needs to accept and what it needs to return. This was very clear. It receives a string that should conform to the JSON grammar and returns the object that the string represents according to the JSON grammar.

// Public interface of the json package
func Load(s string) interface{} {
    return nil
}

Next, I wrote a switch statement that calls the right load function based on the type of value represented by the string passed to the Load function.

/*In Go, public functions are functions that start with a capital letter.
interface{} is the empty interface that accepts a value of any type.
If you are alarmed by the use of a name like 's',
this is consistent with naming used in a lot of Go code.
Go programmers use shortnames often as long as the scope where it is used is small.
I used to be anti-shortnames but I am more comfortable with it now.
*/
func Load(s string) interface{} {
    switch {
    case isString(s):
        return loadString(s)
    case isArray(s):
        return loadArray(s)
    case isObject(s):
        return loadObject(s)
    }
    default:
        panic("unable to parse this string")
}

The nice thing about how this code is currently structured is that when we need to support new types, I just need to add another case statement without modifying what already works. I could also have written this such that I had a map from the check functions (functions prefixed with is and that return a bool that indicates if a string represents a given type) to the corresponding load functions (functions prefixed with load and that actually return the value represented by the string) but the switch statement works well enough right now.

String Parsing

The first step to parsing a string is to check that the string passed into Load represents a string. It’s a string if the first character is a quote so isString is simply this

func isString(s) bool {
    return s[0] == '"'
}

The loadString function looks like this

/*
note that loadString starts with a lowercase letter,
in Go this means that the function is private which mean
can't be used outside the package in which it was defined.
This is a good thing because it minimizes what you
expose to clients of this package which means that you have more
freedom to change implementation details like this function.
*/
func loadString(s string) (int, interface{}) {
    current := 0
    start := current
	current++
	for current < len(s) && s[current] != '"' {
		current++
	}
	// start+1 so we don't include the '""
	// and current + 1 since the next not visited character is at current + 1
	return current + 1, s[start+1 : current]
}

Array Parsing

An array is parsed when Load is called with a string argument that represent an array. A string that represents an array starts with [. This is checked by the isArray function.

func isArray(s) bool {
    return s[0] == '['
}

My first version of loadArray function looked like this

func loadArray(s string) []interface{} {
    array := make([]interface{}, 0)
    current := 0
	current++ // move past '['
	var item interface{}
	for (current < len(s)) && (s[current] != ']') {
		item = Load(s) // load the json value
        if s[current] == ',' {
            current++ // move past ','
        }
		array = append(array, item)
	}
	return array
}

but this doesn’t work for all cases. It works for loading [], and ["abc"] but once you try to load ["abc", "def"]. it doesn’t work like expected.

The problem here is that there is no memory of what we have parsed from the string so far. This means that this line - item = Load(s) just keeps picking up the first item.

This is a fundamental design flaw. To fix it, I had to add a parameter called current that’s an int to the all check and load functions. The value of current is the next index of the string that hasn’t yet been parsed. This is a major decision so I had to modify all the functions so they look like in the snippet below. Note that the public interface (ie. Load’s function signature) didn’t need to change at all.

package json

func Load(s) interface{} {
    value, _ = load(s, 0)
    return value
}

// the second value that is returned is the next position in the string that has yet to be loaded
func load(s string, current int) (interface{}, int) {
    switch {
    case isString(s, current):
        return loadString(s, current)
    case isArray(s, current):
        return loadArray(s, current)
    case isObject(s, current):
        return loadObject(s, current)
    }
    default:
        panic("unable to load this string")
}

func isString(s string, current int) {
    return s[current] == '"'
}

func loadString(s string, current int) (string, int) {
    start := current
	current++ // move past the first '"'
	for current < len(s) && s[current] != '"' {
		current++
	}
	// start+1 so we don't include the  begginning '"'
    // and current + 1 since the next not visited character is at current + 1
    current++ // move past '"'
	return s[start+1 : current-1], current
}

func isArray(s string, current int) bool {
    return s[current] == '['
}

func loadArray(s string) ([]interface{}, int) {
    array := make([]interface{}, 0)
    current := 0
	current++ // move past '['
	var item interface{}
	for (current < len(s)) && (s[current] != ']') {
		item, current = load(s, current)
        if s[current] == ',' {
            current++ // move past ','
        }
		array = append(array, item)
    }
    current++ // move past ']'
	return array, current
}

This works for ["abc","def","gef"] and the also for nested arrays like ["abc",["def",[]]] note that it doesn’t support whitespace. so this ["abc", "def"] doesn’t work yet.

Object Parsing

Parsing objects is very similar to parsing arrays. The code looks like this

func isObject(s string, current int) {
    return s[current] == '{'
}

func loadObject(s string, current int) (map[string]interface{}, int) {
    object := make(map[string]interface{}, 0)
    current := 0
	current++ // move past '{'
	var item interface{}
	for (current < len(s)) && (s[current] != '}') {
        key, current = loadString(s, current)
        current++ // move past the ':'
        value, current = load(s, current)
        object[key] = value
        if s[current] == ',' {
            current++ // move past ','
        }
    }
    current++ // move past '}'
	return object, current
}

This works for {"key":"value","k1":"value2"} and when s represents a nested object {"k1":["abc","cde"],"k2":{"k1":"v2"}}

And that’s it for the MVP!

This is roughly the state at this commit. Note that the naming in that commit is a bit different. For example, loadSequence instead of loadArray and loadMapping instead of loadObject. This was influenced by previously reading the YAML specification which uses the term sequence for array and mapping for object. Naming is important and I have learned to stick to consistent names. In this case, I want the names to be consistent with the JSON specification. That commit also has support for handling whitespace which I would discuss in later posts in this series.

The next post is going to be about how I refactored this MVP. For example, you would notice that I am passing in s, current into all the functions except Load. Is there a missing abstraction that captures what those two variables mean? Also some of the naming is not quite right yet e.g current and Load, can I come up with better names?

Stay tuned!

Thanks Vanessa, Adaobi and Memuna for the reviews.