stz

iterating #2

Now that we've solved the syntactical problems of iteration we can circle back to some of the other ideas before we embraced python comprehensions. The one in particular I'd like to look at is composition of blocks. We know we can use the parameter type → return

stz

implicit first parameter

There has been, from the start, the idea of receiverless method calls where the receiver was bound to the current execution context. The 'self' variable, for want of a better name, didn't need to be written out. adult := self age ≥ 18 adult := age ≥ 18 In the

stz

iterating

One thing that I like to explore is the nature of iteration. In many C like languages you have for. for is a very powerful tool but it is not extensible. Some languages have bent over backwards to put as much power in to for as possible so that you

stz

safe iteration while modifying lists

Lists are arrays + a memory allocator so that upon modification it can reallocate its data array if necessary. They are essential to computing but they aren't thread safe. Not even coroutine safe. But we can fix that. A safe variant that costs a teenytiny bit more during modification

stz

the big syntax updated

It's been N months since the last 'syntax so far' post so it's probably time to revisit absolutely everything. If you're reading the blog in order then this is a spoilers page. Revisit it any time you want to know how the

stz

alternatives to |

Let's explore some alternatives to | used to separate signature from type. w scroll-by: d | w: &widget, d: (vec2 of: float) -> ø [...] w scroll-by: d • w: &widget, d: (vec2 of: float) -> ø [...] w scroll-by: d · w: &widget, d: (vec2 of: float) -&

stz

the naming of types

I've been skirting around a problem I introduced early on because I'm not sure what the best answer is. The naming of types. I have noticed that in a lot of new indie languages they do things like declare primitives types all lower case: int8, uint,

stz

default parameters

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

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

what if no method syntax?

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

coroutines instead of closures

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