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 c…

Is this Python? I didn’t know it had a match statement! This is what I did for Go: [carbon] 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.

Anyone implementing the interpreter using a different pattern than Visitor?

Challenges

andy1li October 2, 2024, 3:02am 3

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:

#IZ6 True being evaluated to True when I want just true

Topic		Replies	Views
Complete implementation of interpreter in Go General challenge:interpreter	2	178	September 4, 2024
Testing Interpreter challenge myself Challenges challenge:interpreter	5	78	October 4, 2024
Future proofing my code Challenges challenge:interpreter	8	143	July 9, 2024
New challenge: Build your own Interpreter Announcements	4	239	July 5, 2024
Test Case 4 in Interpreter #PG8 (Functions without arguments) seems out of place Challenges challenge:interpreter	3	24	November 14, 2024

Anyone implementing the interpreter using a different pattern than Visitor?

Related topics