stz
One of the most painful things about writing this kind of compiler - one in which the compiler itself runs an interpreter and one where I don't want to implement the parser multiple times - is that the compiler needs to be able to create the same structures
stz
One thing that is always awkward with traditional Smalltalk syntax is making object trees. I'd like to know if stz has improved on that with its new syntactical capabilities. Let's try and build a HTML page using {} and then again using interpolated strings. page-title = 'Hello
stz
When we send messages without a receiver I have been treating it as if we're sending messages to a compilation scope context object. Just what that object does is a bit up in the air right now. It binds things in to a map of name → object and
stz
I'd like the stz compiler (stzc) to be very very fast. So fast you don't have to think about waiting to try out your changes. So fast it might as well run in the background monitoring file changes and recreating the program as it goes. For
stz
For many days now we've been embracing the syntax: { type | calls... } to create something on the stack. At compile time the type is computed and that tells the compiler how to construct the stack frame. But do we need it? What is a variable? when it's
stz
We can scope methods easily enough: public [ a-public-method | -> ø ] package [ a-package-method | -> ø ] private [ a-private-method | -> ø ] But when we want to create a class or a trait we suddenly lose that granularity at the variables and constants level. It is an array after all. But
stz
Strings are a powerful beast. They can come in many different forms and encodings. Some have character escaping and others have interpolation. In a previous blog post we realised we needed more than just plain characters for our strings. The first rule of thumb to make is all compilation strings
stz
When we send constants: to a class or a trait we're not just recording that there is one but we also want to generate a method for accessing that value easily later. The simple example: iterable-t = { trait | constants: ( element-class: class, ) } We want that to produce a method like
stz
It's time to talk about the compiler. The compiler has to provide a minimum level of capability so that the rest of the code can construct itself. Without the compiler there is no point to Smalltalk Zero. (Part of me does wonder if stz can eventually elevate itself
stz
Currently traits have a property called requires: which is an array of method signatures. We need a way to specify more than just implementations that must exist for a class to be part of a trait group. Let's segway a moment and figure out what a class even
stz
Breaking down the class definition we have a problem: list = { class | parameters: (of: object-t,), constants: (element-class: of,), traits: (sequenceable-t of: element-class,), variables: ( elements: &array of: element-class, length: uint, allocator: &memory-allocator,) } The constants section references a variable that doesn't exist. The traits section references a variable that
stz
Just as an side back to the getters and setters of Person's name. My intention is that declaring the class auto-creates the getter and setter for you. Person = ( name: string, age: (quantity of: seconds) ) However, how do you specify which variables you want to be public and which