stz talking to the void

stz talking to the void
Photo by Ali Jafarov / Unsplash

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 it keeps track of if those bindings should be public, for packages, or private.

We settled on declaring variables with the syntax variable-name: a-type and that looks very much like a message send too. That does suggest we are sending messages to the compilation scope context and when it doesn't understand it it adds it to the scope of shiny new things.

It also means we can simply send public private and package without a receiver. It also means we can define methods without receivers who exist within our current compilation unit. They can even be public - but since the receiver is a compilation unit they cannot exist at runtime.

Does that mean receiverless only exists at compile time? Maybe. For now let's just content ourselves with the knowledge that this mystic receiver exists. If we make too many assumptions about runtime vs compiletime we might get in trouble.

I do find it rather interesting that 'procedural' programming is helpful at compile time. Mostly because it's a bit like scripting. You want to write some code but not be explicit about what the script is - or even have to name it. It is enough that it exists.

We'll also start introducing the use of package: 'my-package' as a first-instruction in any file to make it clear what the scope of the following code is. This also allows a package to be 'extended' by including a file in your compilation unit that uses the same package name.

This is where we might have to start name spacing packages. We'll treat it like a file system and use /, eg:
core = using: 'stz/core'

An implicit 'core' variable (of type package) would be declared with a using: 'stz/core' declaration.