node tree

Let's try and code something simple. A tree of nodes: Node (name: String, children: (Array of: Node)) We can likely use this right away to simulate HTML (without attributes): document: Node = {name: 'html', children: ( {name: 'head'}, {name: 'body'}) } Let's keep

zero cost reinterpretation

Sometimes you have a piece of data and you want to treat it differently to how it currently is. Let's take a concrete example: a filename. Not a file, but its name. It could include a path, it might not. Underneath it all, it's a bunch

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

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

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

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

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

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

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

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

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

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) -&