stz

stz

I/O definition vs execution

In previous examples of IO I've been using the null-type to make a pipe of operations execute. Let's break this down a bit and find a better way to do that. people | [age ≥ 18] | stdout To better understand how the flow operates we should look at

stz

forms of [] and the ~

I added the ability to declare methods using signature ~ types [ code ] recently and it hasn't sat well with me since. The short hand for doing inline methods remained [ signature | types | code] and the way you write blocks is either [ types | code ] or [ code ]. I'm going to

stz

pattern matching unions

Currently you define unions in such a way that you can re-interpret the data in another form. This is the class C style union. pet (union | as-cat: cat, as-dog: dog) But what if we wanted tagged unions? essentially a type+data? To be useful we need to be able to

stz

the invasive maybe

Maybe is a really powerful concept. It's sometimes called Choice and it has a few other names too. The basic idea is a structure of 'value' and 'state' where that state might be an error-code, or it might simply be a true/false indicator

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: