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.
stz
Systems level programming and closures. Look, it's not really a Smalltalk if we don't have closures. But that doesn't mean we can't be more specific about how it works. using: 'core/memory' export: [ main | memory allocate: (fixed-array size: 10 of:
stz
We know how to export things and we know during compilation we're running in the compilation-scope-context. So how do we pull things in to that from other compilation-scope-contexts? First we should side-bar and talk about source code management. Smalltalk has always had a long history of doing its
stz
There's two kinds of object instantiation we care about - on the stack and on the heap. On the heap is an act of memory allocation using a memory allocator, while on the stack is a core concept in the language. Currently we have no syntax for declaring
stz
One of the most interesting ideas from Smalltalk was 'literate programming' which has become known also as keyword selectors. Instead of a single magic command followed by a bunch of arguments you place a keyword before each part of a method argument, eg: aGraphicsContext displayLineFrom: start to: stop
stz
C pointers are ... a thing. Not a good thing. But a thing. The name 'pointer' is also ... a thing. What we really have is an address in memory and we get or set things from it. We don't know how much of a thing we have