stz
Now that methods and blocks both use the same syntax for describing the arguments, it dawned on me it's trivial to add in default parameters. my-block := [ a: int = 1, b: int = 2 -> r: int = 1000 | a > 0 then: [ r <- a + b ] ] my-block evaluate:
stz
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
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
Now that method parameters and code block parameters are done the same way it does strike me as odd that we have two ways of naming a block of code. One as a method and one as closure. thingy-closure = [ n: int -> r: int | r -> n + 1
With coroutines being so core to the execution engine of STZ it does make me wonder - do we really need closures too? There's actually two kinds of closures. The first kind is passed on the stack and dies when the stack frame that defined it no longer
It's been a very long while since I've coded coroutines in C. I had naively thought that I could call getcontext and setcontext and be done with it. Well, it turns out that was wrong. In 2016ish? POSIX decided to deprecate the makecontext/swapcontext/getcontext/setcontext
I've never used cisco gear before. It's always been out of my price range and/or need. But I found myself wanting to get rid of the security box hooked up to our home cameras because it kept trying to contact alibaba. With the camera reconfigured
stz
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
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
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
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
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: