Smalltalk Zero
stz
It dawned on me looking at some old notes that I once had an idea for generic container using the sub-index syntax. Instead of Array of: Person you'd write Array[Person]. I wondered - well, can't I do that in STZ right now? and do I
stz
Instead of writing an interpreter, what if we built the language so it compiles every layer from the very bottom to the very top. What limitations would we need to place on ourselves to make that possible? The first thing we need to consider is what the output of the
stz
Template strings solve a lot of text based feedback problems. Instead of having string builders and concatenations and memory allocation headaches, we can instead create a composite string using a template. [self make-html: page] [self: Progam, page: Page -> String | `<html> <head> <title>
stz
Signed and Unsigned Integers are pretty core to programming in a not-assembler level language. For STZ I'd like to represent Signed and Unsigned Integers as, internally, binary data. bits: (Binary of: 8) = 0b01010101. How many bits you have determines what kind of storage it can fit in to.
stz
Meta-programming is an important capability to have in a language. It's not necessary if you want to build every bell and whistle in to a language at its core, but it allows you to incrementally improve a language if you know you won't have it all
stz
Consider this innocent method: [list add: element] [List of: element, element -> list | ...code goes here...] And now ruin its day: list :: 1. element :: 2. What does this mean? We've now effectively locked the method signature to only one use case: 1 add: 2 which will fail
stz
We twisted our arm a little bit to make stuff in a second allocator and then copy the result back in to the first allocator. It'd be better if it were allocated in the first allocator to begin with and we didn't have any temporary stuff
stz
STZ is multithreaded. Therefore globals that aren't const are very bad. We still need a way to conveniently pass around some 'global like' information though. Let's consider the most important one - memory management. There's a school of thought that says you
stz
The idea that we can support different kinds of coroutines libraries in STZ makes me happy. So much so I think it's worth abandoning the Smalltalk-80 fork API and providing the libraries as-is, with some nice wrapping to clean them up. Tina provides us not only with asynchronous
stz
Let's approach coroutines as something we utilise rather than get in the language. Using the minicoro library and the ability to use C code directly from STZ, let's see what it'll take to utilise. Starting with the basics - let's create a
stz
It will come as no surprise to people who know me that using <> as a grouping mechanism for any kind of information is distasteful. It visually conflicts with less than, greater than, etc. It's already visually conflicting with select> and do>. I made all
stz
(Integer | 1,) (my-object | b | c) (MyType | my-object | b | c,) The | is used in a lot of places to delineate between 'the type' and 'the code' inside of list creation (type | ...elements...), methods and blocks [type | ...code...], new object {type | ...code list...}. We have also been using