stz

stz

whitespace matters?

I'm sure there'll be plenty of people who hate the very idea of exploring this. But what if we took a page out of Python and made whitespace matter? There will numerous problems with this but let's at least give it a try. a

stz

a different module syntax

One of the guiding features of stz is compile time scripting to help produce the runtime. That has meant allowing code at the top level of a file. That has also meant that the syntax for declaring a method needed to work anywhere, as regular syntax. But what if we

stz

unexpected syntax

As I'm making an experimental parser for stz I came across something interesting that I'd overlooked. It all stems from the type information in a method or a block (or a signature): [ a foo: b | uint, uint -> uint | ... ] It's the uint, uint

stz

the mac keyword

This is the kind of decision that can upset an ecosystem. Anyone who has owned and programmed on a mac for a while knows that we can write ≤ ≥ and ≠ super easily. It makes it oh so tempting to use these unicode symbols in the language because they are the correct

stz

revisiting bang!

I really like prefix symbols in a programming language. Being able to write !some-boolean-test to do a 'not' is so deeply ingrained in to me and I don't want to change it. In Smalltalk we send not to the object, eg: some-boolean-test not. It is a

stz

revisiting pub/private/package

I don't like #scope: private. One of the main reasons I don't like it is private and package have 7 letters and public only has 6. Also it's just plain ugly. I miss the days (a week or so ago) when I could just

stz

revisiting specialisation

While driving eight hours I had some time for focused thinking. Since I'm deep in writing a parser for the language I was contemplating some of the stickier corners of the syntax. Last time I talked about specialisation I made an error. I came up with this syntax:

stz

parsing structures

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

object trees

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

talking to the void

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

incremental compilation

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

killing receiverless

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