Anyone implementing the interpreter using a different pattern than Visitor?

In the book, the author chooses the Visitor Pattern for their implementation, which makes a lot of sense for an object-oriented language like Java. I know it’s possible to use this pattern in Go as well, but because we don’t have classes, I find it a little unergonomic to use it. I decided to just create recursive functions that do type switches.

It’s been interesting to do this challenge in Go because I have to kind of “translate” the deeply object-oriented approach to the book’s implementation into more idiomatic Go code.

2 Likes

I implement the interpreter to learn Go along the way. Even though Go is not an OO-language in the strict sense I found the availability of interfaces, structs and methods sufficient to use the visitor pattern for my interpreter. But - as I said - I am a Go newbie. so this might not be an idiomatic approach in Go.

2 Likes

I found the Visitor Pattern cumbersome as well, especially in languages that don’t have to use class for everything.

It’s arguably cleaner to use pattern matching with destructuring, for example:

Is this Python? I didn’t know it had a match statement! This is what I did for Go:

Each one of these functions end up recursively calling Evaluate(expr) until the expression passed is a Literal, in which case its value is returned. Simple and clear recursion.

1 Like

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.