Smalltalk Zero
stz
Before we can write an interpreter or compiler we need to be able to parse the syntax of stz. The rules are fairly simple so far. There's a few characters that are special: start-bracket ( stop-bracket ) start-block [ stop-block ] start-make { stop-make } divider | return ^ string-quote ' " ` reference & keyword-break : comment-start
stz
Writing out enumerated values should be as simple as listing them. For instance: north = 1 east = 2 south = 3 west = 4 The whole point of enums though is to scope them away inside a namespace. To use the enum as a type. The problem with throwing random names out there
stz
When we reviewed the syntax so far we ran in to a problem with arrays and maps. We don't have syntax for them. What we have so far is the ability to make an object on the stack: { the-class | messages to send to the class... } If we stick
stz
Writing a whole compiler from scratch is a lot of work. There's so many parts to it from SSA to instruction fitting to register allocation optimisation and constant folding and and and... I don't really want to do all that. The simplest solution is to transpile
stz
Something that can save a great deal of headaches in programming is defer. file-handle = io open: 'foo.txt' mode: io O_RDONLY defer io close: file-handle In Smalltalk, with garbage collection, we can be told by the garbage collector that something is being destroyed. Things like IO will
stz
making an object: { expression | expression list sent to the new instance } making a class: my-class = class: { list of variable: expression list } making an enum (* note #1): my-enum = enum: { list of names } array of things (last , is optional): a, b, c, empty array () making a union of classes: first-class + second-class making
stz
In a previous post I wrote this piece of code: [ list add: element | &(list-of: (class-of: element), (class-of: element) | capacity == length then: [ grow ] elements[length] = element length += 1 ] The signature has three sections: 1. the pattern that will be used when calling this method 2. the types that must match
stz
So far we've been using a stand-in syntax of $name to indicate an unknown type. This being borrowed from languages such as Go, Odin, Jai, etc. But if we have an interpreter helping us build our compilation unit is it really necessary? Let's try and create
stz
I don't like export:. Perhaps something better can be done. There's three scopes of we care about - public stuff that can be imported or used; package stuff that everything in a package can see; private stuff that does not leave the file it is in.
stz
We can name objects locally by assigning it to a variable, eg: person = { name: string, height: distance } We can also specify what kind of object to make with the {} syntax, eg: origin = { vec2 of: float | x: 0, y: 0 } But if we want to export it, suddenly we have to
stz
Do we always need a receiver? the idea behind 'message sends' was that an object is sending a message to another object. It's a fun idea. But sometimes it's awkward to choose one parameter over another, eg: start to: stop do: block This looks
stz
We have to start this story with tail call optimisation. The story of the stack is an interesting one. It is convention to keep the entire history of your call pathway on the stack in most languages. This allows you to debug what went wrong which can be super useful.