In Chapter 1.3 of [Ball’s Writing an Interpreter in Go][1], we encounter one design decision of his Monkey programming language. Here, the lexer has a NextToken() method that looks like this:

func (l *Lexer) NextToken() token.Token {
    var tok token.Token

    switch l.ch {
// [...]
    default:
        if isLetter(l.ch) {
            tok.Literal = l.readIdentifier()
            return tok
        } else {
            tok = newToken(token.ILLEGAL, l.ch)
        }
    }
// [...]
}

This means the lexer itself does not do backtracking. The meaning of a character at any point cannot be ambiguous. You cannot say, for example, that ‘+’ is the ‘plus’ token unless it is in the middle of a variable name. I don’t know many programming languages that support such behavior – so it is probably an acceptable design decision. You know what they say, “Keep it Simple, Smartypants”. I’m not sure if there are other notable constraints introduced by the design at this point, but it is something that tickles my overly analytical brain.

A lexer takes the source code, a sequence of characters, and group them into tokens. e.g., it makes the first decision on how to process the strings 100-10, -100-10, and -100--100 into groups. I’m going to call this grouping “tokenization” even though I may be misusing the term.

Tokenizing source code is hard. How should -100--100 be tokenized? Should it be a literal -100 followed by the minus token, followed by another -100?

Writing an Interpreter In Go by Thorsten Ball will be my personal introduction to writing an interpreter. I’ve never taken a comp sci class before, so I know nothing about compilers. On a lark, I decided to explore this area now, nearly 20 years after I started to learn computer programming.

If you are interested in this book as well, you might might the AST Explorer a useful companion.

I was told as some point in the past, that compilation can be broken down into four stages:

It happened. At the recommendation of https://twitter.com/dgryski, I bought Writing an Interpreter In Go. This will be my next hobby project. It’ll be interesting to see if I ever finish it.

Lots of small things today.

History

“Those who cannot remember the past are condemned to repeat it”. I love reading about how software came to be the way they are today.

Before we can talk about where generics are going, we first have to talk about where they are, and how they got there.

https://cr.openjdk.java.net/~briangoetz/erasure.html

Go Errors

Error handling is still jacked in Go 1.16. That is, the formatting change is still not present. Why is this a problem? There are two use cases for errors. Error as values, which can be inspected programatically, and error printing, which is not meant for programmatic consumption.

In this part of the series, we’ll write some hands-on Temporal code and run it. Let’s start with our requirements:

You need to transmit a data packet. You can choose from multiple Route Providers to do this. Transmission takes time – you will be notified on a callback URL when the packet is delivered. Delivery may fail – either because the acknowledgement was not sent or arrived late (because Internet). You should try the next provider when one fails.

I spent a couple of hours evaluating 3rd party libraries. What have I learned? For me, there’s one clear winner in a small field of candidates.

Presently, these are the top hits for “golang gauge counter timer”.

1. https://pkg.go.dev/github.com/go-kit/kit/metrics
2. https://pkg.go.dev/github.com/facebookgo/metrics
3. https://github.com/uber-go/tally

The first result is go-kit. Go-kit isn’t a metrics library. Rather, it bills itself as a “framework for building microservices.” Its metrics package is simply a set of interfaces. You then refrence one of the many sub-packages with concrete implementations. As a consequence, it’s go.mod file is pretty huge.

Go does not allow cyclic imports. A solution is to create a “shared” package to hold interfaces that related packages all reference. This, for some reason, reminds of me join tables in SQL.

Here is an example of a typical Go project. Packages toward the bottom, e.g., “common/persistence”, allow different packages to work with each other without introducing cyclic dependencies. For this project, “log” can be referenced by “config”, but cannot use “config” to conifgure itself.

Oldie but goodie. Go concurrency patterns

https://drive.google.com/file/d/1nPdvhB0PutEJzdCq5ms6UI58dp50fcAN/view

In A Tour of Go, it states “Go has pointers. A pointer holds the memory address of a value.” When you design your data structure in Go, you have to decide between using a pointer or not. There’s no clear rule of thumb for it.

I had been reading the Go source code to AWS’s client library for DynamoDB. For a while, I had been annoying with their API design, which looks like this: