quick note: i’ll put a dagger symbol (†) next to any jargon i’ve made up, and i’ll leave it out if i’m pretty sure the jargon is real. im trying to do a little novel classification here, so.

let me tell you about

modules

a module is a way to organize lots of behaviors under one scope. there are a few kinds of modules, and i want to suggest that these interpretations form a hierarchy. we’re going to start with the narrowest end of the hierarchy and work our way up. and it’ll be more relevant as we get to the ocaml section but we’re discussing modules strictly as they exist dynamically, at runtime. no types here, sorry!

static modules†

this is like what Haskell calls a module, or what many languages (Python, Kotlin, etc) will call a package.

package org.example

fun printMessage() { /*...*/ }
class Message(val text: String) { /*...*/ }

(from https://kotlinlang.org/docs/packages.html. okay, kotlin does have things it calls modules but it’s the package that’s more relevant here. kotlin’s nominal modules are more strictly compilation units.)

these modules do nothing beside providing a scope and disambiguating names. so i can have a module which provides org.example.PrintMessage as above, but I can also have a secondary module which provides org.example2.silly.PrintMessagee. so let’s quantify what this kind of module does for us:

• name disambiguation
• scoping and privitization
  • you can choose to not export a name from a module
• dependency demand†
  • you can import a module from another module, bringing its names into scope
  • notably you cannot do this arbitrarily, you MUST do this in an acyclic way in most languages, which will not do cycle analysis on this graph
• compilation unit separation
  • if a module hasn’t changed, it doesn’t need to be recompiled. this comes for free because of the scope boundary

closure modules†

there is a middle-ground for how dynamic a module can be. instead of all data specified in a module being completely static, you can also have modules which close over some data explicitly and work with that data as state.

a particularly interesting example exists in Maude’s system modules, in which entire rewriting theories can be scoped to a given module. a user may work with these modules as first class theory objects and may, for example, do invariant checking directly on the module.

modules as interpreted this way share a behavioral overlap with singleton classes. in a singleton class, we expect to only have one single instance (which may be statically identified by the class declaration), and this single instance can close over data and update itself. some singleton classes can even nest.

note that I’m NOT saying that these modules support implicit closure over some environment. we’ll touch on that in the next section.

let’s take a note of this capability:

• explicit closure
  • you can choose to store data within the module, and you can choose to come back and mutate that data

polymorphic modules†

we’ve made the singleton class comparison, so let’s extend that a little more. what if we could have N singleton classes, where each one was parameterized over a set of types and values?

i believe this to be equivalent in power (or actually just equivalent) to the sanitary macro. and as such let’s talk about the C++ STL. check out this example:

template<typename T, T V>
class SingletonValue {
public:
    static T value() noexcept { return V; }
};

invoked as

auto x = SingletonValue<int, 42>::value();   // gives x == 42
auto y = SingletonValue<int, 69>::value();   // gives y == 69

in the jargon of the hierarchy we’ve built, SingletonValue IS a polymorphic module. it is parameterized over a set of types and/or values (we could have used auto to drop the typevar fwiw). it does all of the behaviors we’ve scoped out above, with the added benefit of also now allowing us to instantiate multiple of these singleton modules. so what extra behaviors does this get us?

• multiplicity
  • specifically, you may have 1 instance of a polymorphic module per unique parameter. so if you’ve got some sort of countable type, you’ve got infinite modules.

functatorial (first-class) polymorphic modules

let’s again expand the breadth of things a module can do—we now allow a closure module to take input. the only place i’ve ever seen this explicitly is in the SML family of languages. specifically, let’s look at ocaml’s functors:

As suggested by the name, a functor is almost like a function. However, while the inputs and outputs of functions are values, functors are between modules. A functor has a module as a parameter and returns a module as a result. A functor in OCaml is a parametrised module, not to be confused with a functor in mathematics.

let me begin by saying that there is a rich mathematical backing to ocaml’s unified module system, which comes equipped with a formal calculus based off Rossberg’s 1ML. a little googling also brought me to this paper, which speaks on a more recent ocaml feature (modular explicits) that allow higher-order functions to operate directly on modules and provides a calculus for unifying types quantified within modules with externally quantified types.

PLEASE take a look at the 1ML paper, and especially the Related Work section, for an academic and historical perspective on this hierarchy of module behaviors. additionally if you’re interested in the type-theoretic perspective and all the cool stuff ocaml can do with structs/model signatures, i’m not going to touch on that at all. I’m talking about modules from a purely dynamic perspective.

(now that i’ve said that, i can continue spewing colloquial bullshit)

the classic example of first-class functatorial modules in ocaml is a module that modifies another:

module type X = sig
  val x : int
end

module AddX (M : X) = struct
  let add y = M.x + y
end

(from https://cs3110.github.io/textbook/chapters/modules/functors.html)

note that this immediately gives us a few new capabilities to think about:

• nesting
  • modules can consume other modules as variables. passing in an anonymous module is identical to defining a module within another module in the effect it has on the environment

who’s janna?

janna (she/her) is a VM for working with modules. in the tradition of naming my compilers after my OCs, so too is she named. she supports a number of actions on modules, and i’d like to take the time to quantify this set of actions so we can get a full idea of how to interact with a module.

janna is a fully dynamic VM and does not have an initial pass for things like type/effect checking. janna is built in the forth tradition of parsing words, so janna’s not even statically decidable. this lets us do fun things with continuations without having to come up with a static managed runtime. if you want all these goodies with a type system on top of it, for Serious Work, go check out ocaml.

the intention is that janna will support first-class polymorphic modules. she will be able to create these modules on the fly and do all the composing you’d like. so let’s start walking up the hierarchy and look at the syntax and semantic of janna.

note that ALL the syntax and spellings here are subject to change, but it’s valid as of 8/10/2026.

quick sidenotes before we begin

janna’s output

i’ll use double boxes for code input vs code output

this is input

and this is output

note that janna has a little debug printer that does its best to dump the VM state. this is what it looks like in a fresh VM, you’ll see it again soon:

?

janna v0 knows 4 modules: io, debug, main, core
open scopes (active scope first): main

within main, there are 0 definitions:

within main, the resolution chain is: debug, io, core

within main, open stacks (active first): hole

within main, there are 1 stacks:
hole[]

janna’s datatypes

janna’s for a gamejam so she’s only getting features on an as-needed basis. janna currently only has two types—terms, which are bare words;

\ i'm-a-term .

i'm-a-term

and quotes, which are effectively sequences of words but stored internally as strings:

[ Hark! O'er the five seas, land emerges! ] .s

Hark! O'er the five seas, land emerges!

if i need something else i’ll add that something else. integers are a good candidate. but without loops or conditionals i haven’t seen the need yet!

static modules

enter: is a syntax word that consumes one name term and enters the scope of the module given by the name. if the module doesn’t exist, we create it. leave is its inverse, : is word definition. we call ? twice so you, dear reader, can get Maximum Info, and see how janna is treating each scope here.

enter: foo
: bar [ hello world ] . ;
?
leave
[ -------- ] .s
?

janna v0 knows 5 modules: debug, main, core, foo, io
open scopes (active scope first): foo, main

within foo, there are 1 definitions:
bar

within foo, the resolution chain is: 

within foo, open stacks (active first): hole

within foo, there are 1 stacks:
hole[]

--------

janna v0 knows 5 modules: debug, main, core, foo, io
open scopes (active scope first): main

within main, there are 0 definitions:

within main, the resolution chain is: debug, io, core

within main, open stacks (active first): hole

within main, there are 1 stacks:
hole[]

scoping, privitization, disambiguation

modules can hold named stacks and named definitions. this does a few things for us: firstly, disambiguation and scoping! watch us distinguish between two different definitions of bar:

enter: foo1
: bar [ hello world ] .s ;
leave
enter: foo2
: bar [ goodbye world ] .s ;
leave

enter: foo1 bar leave
enter: foo2 bar leave
bar

hello world

goodbye world

Unknown word bar in modules ["main"]

dependency demand

compilation unit separation

… is nonapplicable because we don’t statically compile.

closure modules

at initialization time, you’re free to pull data from other names

polymorphic modules

enter (not enter:) can take a quote as the name of the module. the first word from the quote is taken as the module name, all subsequent terms in the quote are taken as the parameter to the module.

TODO: maybe the subsequent words should be “the name of teh stack that we push the parameters to”…. much to think about?

TODO alternate: this parameter is automatically populated onto a named stack within the module, M.T.

first-class modules

TODO: there should be an anonymous version of enter, and leave should push the name of the module to the stack.

janna’s bag of tricks

special modules (like the parameterized module that holds continuations)

lots of people are posting lots of cool things that they have prompted a large language model to create. lots of my time gets wasted trying to figure out if there is a human with intention and skill behind a project; or if the thing is the product of channeling machine spirits via a federal-money-pit-subsidized monthly credit.

set aside all your moral, legal, intellectual-property, environmental, risk-tolerance, economic, geopolitical, and long-term-tech-debt related qualms with ai for a moment. lets say that ai Rules, actually, and nobody’s ever had their tap water collared by a surveillance datacenter that will never have the budget to upgrade to a closed-loop system. lets just say that for a moment and let’s fully accept that AI as it exists has no externalities to speak of.

there are two kinds of software projects i care about:

you made a tool.

that’s awesome. maybe it saves you time, maybe it makes a difficult task easier. that’s a totally valid use-case for LLM generation—no need to waste more time on a means to an end than you’ve gotta!

but like—why do i care about your tool? what do i actually want to read about your tool?

if it’s directly relevant to me then maybe i’ll take an interest to the use-case and download it. but so many cool tools exist that i wouldn’t ever need to use, so it’s safe to assume this one’s not really gonna change my life either.

despite that i would love to hear about the challenges you faced while making the tool. your design considerations and your UX iteration. tell me how your tool scales or about wacky ways to use the thing. tell me about the rough edge your tool had that you smoothed over after some big breakthrough you synthesized while watching Breaking Bad. let me learn from not just your artifact but from your methodology.

except, you didn’t think about any of those things. you prompted a robot and gave it maybe an example invocation, a sketchy drawing, or described a few of its command line flags. but more likely you iterated with the robot to figure out how the tool would work at all.

i don’t want to read your chat logs. i can pay claude three dollhairs and recreate your logs and your whole tool in the time it takes me to get lunch. hearing this process teaches me nothing. seeing your >1k LoC artifacts only tells me that you voluntarily opted to send money to a frontier inference provider. samuel alterman, dario amodei, along mask, and tongy stark need that cash. and you needed to purchase some thought.

i’ll be at the south indian lunch buffet while my rip of your tool is being created. an improvement in every promptable way—hashtag yolo mode bros! i’ll have a second agent iterating on the friction in common user stories, a third agent iterating on security vulnerabilities, and a fourth agent just refreshing your tool’s github to make sure i never lose feature parity. i won’t know how to use either of our tools until i read the readme or feed it back to a bot to summarize. i learned nothing. i filled a gas town ralph wiggum jira board with alphabet soup. my tool will beat your tool’s ass though, because i threw an extra few loops at it. $3? $300. but mine installs autonomously, just copy and paste this easy prompt directly into your agent. $3? no, $6, you had to rerun the install because it stochastically decided to purge your local npm packages instead.

you made an art.

that’s awesome. that’s really cool. i can’t believe you painted this. i’m in awe of your skill.

[…]

no, you didn’t use paint for this? but you said you painted it right here—right in the attribution placard.

[…]

i guess that’s understandable, i also don’t know how to paint well enough to put something like this together. and besides, painting something this huge would take sooo long. it could even take years!

[…]

so this is just a photograph?

[…]

well, i guess that’s fine. i’ll take you lying about the medium as part of the artistic experience. the thing still looks like you did a little digital brushwork though… tell me about your thoughts here!! what brushset did you choose? why’d you vary the energy like this?

[…]

oh, you just had a tool lay out brushstrokes for you?

[…]

i guess you did. now that you say it, i can even see the same bit of ugly aliasing on the edge of this brush stamp repeated in a bunch of spots around the canvas.

[…]

really, i know how helpful the auto-brushstroking tool is. like, each of those strokes would have taken a solid five minutes. but you didn’t even try to fix up that aliasing.

[…]

you didn’t notice the aliasing? did you look at this piece before you submitted it to the gallery?

[…]

fine, whatever, you looked and you didn’t notice. can you at least tell me about what motivated you to paint this particular landscape?

[…]

you didn’t take the original photograph?

[…]

you just liked the vibes of some of the other photographs you’ve seen?

[…]

so… what did you actually do here? it seems to me like all you’ve done is feed the machine a vague idea and then clicked on the prettiest pictures it spit out for a few hours.

[…]

i don’t really think anything new is possible with a workflow like this. maybe you can do more of these canvases but was that really what you wanted to fill up your portfolio? they don’t really tell a story or say anything about you. this kind of just feels like you wasted both of our times.

[…]

you know, you’re right! oh but it works! yeah it really does! it DOES do what it says it’ll do in the readme on the placard! and i can see it working right here! it might actually have a high chance of doing what you said you asked it to do! and it really does resemble human brushstroke! and that was worth all of this kerfuffle, i guess!

of course there’s other crap. i waved it all aside at the start. yeah of course every corporation is slinging ai slop at a far higher rate and a far lower quality bar than individuals. thats called “the commodification of labor” and you need to read a little Engels. yea of course there’s sketchy backroom deals and dark money funding triggering a massive credit bubble. thats called “politics, baby” and you gotta ride the wave. yea of course shmalterman horrifically assaulted his sister as an adolescent. that one’s a classic diagnosis—”narcissism”. and yea of course your grandma is looking at ai memes on fAIcebook. that one’s just called “your bloodline has been forever cursed”. sorry!

the only way to break the curse is to do crochet and play video games that have a no-AI disclaimer attached. or, like, seriously consider logging off.

This post is going to be the quickest whirlwind of everything that comes to mind that I’m excited about this year. It won’t be in chronological order, and it might not even all be 2025~ I’ve been spending a lot of

New jobs!

First half of the year, I was writing Golang for $BIG_FINANCIAL_COMPANY. Second half of the year, I’m writing Golang for $BIGGER_FINANCIAL_COMPANY. Have you ever seen me write Golang? No… sometimes you find the niche, sometimes the niche finds you.

New servers! New hardware!

I’m building a data storage rack. I’ve currently got:

• the rack itself
• a power strip
• two Pi 4’s
• a shoebox as their containment unit
• a fancy network switch
• and two DVD drives for, you know, ripping old shovelware that’s run out its copyright. And other activities of that nature.

Please please please – if you know of a large 6-10 drive 12in depth 2-3u cost effective drive bay please let me know! It’s fine if I get ‘em used, I just hardly know where to even look to buy something like this. I used Synology at an old job, but the company’s went down the shitter and they lock their new systems down to only use their drives…

New languages!

I’ve been working on a LOT of language projects this year. Esolanging has yet again captured my imagination, binding it with a knotty fervor unrivaled by the best sailors. My mind drips sweat. It pants and begs to be let—- wait, where was I? Esolanging, right. I got carried away.

Most of this is imported from Discord. It’s much easier for me to pop in there, wax poetic about some fake language for five minutes, and then disappear back into the ether. I’ve spent a lot of time in the concatenative discord server lately. Join there and join the server in my blog footer, then finish reading.

Rosin

Hey, this rings a bell! I started this during last year’s december adventure. Which also happens to be my last blog post. Oh no, has this blog become a once-a-year venture? I hope not! Writing is invigorating. It just so happens to also be tiring.

Anyway, Rosin has come incredibly far. There is a formal spec, there’s a pretty large test suite, eager variables are actually useful now in that they make the interpreter run until fixpoint on a particular tree. There’s a README that is like 6 months out of date (oops! hehe), I’ve covered most of the features I’m interested in covering.

The compiler’s gone through a bunch of iterative improvements that have drastically improved the codebase. Big ups to @microchipsndip on Discord and evincar for the suggestions. I would have never learned how I’m actually supposed to use mtl without these fellas.

A few functions I’m extra proud of:

• The core pattern matching function: https://github.com/DataKinds/tree-rewriter/blob/main/src/Core.hs#L237-L276. I daresay this function almost reads like pseudocode.
• The runtime stepping function: https://github.com/DataKinds/tree-rewriter/blob/main/src/Runtime.hs#L243-L287. Finally reaping that sweet, sweet monadic DSL glory.

Next is support for subinterpreters and parallelism (think Ruby::Box). Maybe also finally using my Trie implementation to match patterns.

Also, I named this language after an OC. She/they’re a demon-woman-changeling with black hair and gray skin that can take the form of a swarm of white-fur-red-eyed mice. Oy vey!

Objective Thue (Thue++? Thue Plus? Parallel Thue?)

Here’s another language idea I’ve been excited about: a version of Thue where you can pass messages back and forth between different rewriting engines that contain their own internal state. I’ve been playing around with the syntax and semantics, here’s some snippets ripped from discord messages:

invoker {
    default a            // If this scope is invoked without an input, what state do we default to?
    strategy pick-first  // Apply the very first matching rule as close to the start of the string as possible
    b+ :~ $              // This rule (using :~) passes the RHS as a return value of the `invoker`, deleting (this is slow... what do?) the LHS from the internal state.
    a := ab              // This rule (using :=) matches the LHS and substitutes the RHS into the internal state of the `invoker`
}

counter {               // Counts the number of a's it's been passed
    strategy pick-first
    a := I
    . :=                // VERY VERY VERY basic regex, anything I can easily compile to a fast FSM. 
                        // In this case: match any character that's not `a` and delete it from the internal state.
    I+ :::= got $ As    // LHS (I+) is another abuse of basic regex. :::= gives a rule that writes to stdout (similar to Thue proper). Deletes the LHS from the internal state.
                        // $ gives the entire match on the LHS. Think regex substitution syntax: $0, $1, $2, ...
}

invoker2 = new invoker "aaa" // `new` is its own scoped object, just provided automatically by the compiler
counter2 = new counter
counter2 invoker2 

// Prints "got III As", "got IIII As", "got IIIII As", "got IIIIII As", ...d

There are so few knobs to turn here that actually make sense:

• Where does the rewrite head start
• What does the state default to
• How does the rewrite head move when it fails a match
• How does the rewrite head move when it matches
• How does the rewriter decide which of many matching rules to select

And a tiny Thue implementation in Raku:

#!/usr/bin/env raku

grammar Thue {
    token TOP { 
        :my $*PAST-DIVIDER = False;
        \v* [<line> \v*]+ 
    }
    token line {
    || <?{ $*PAST-DIVIDER }> <slurp>
    || <divider>
    || <rule>
    }
    token slurp { (.+) $ }
    token divider { 
        ^^ '---' $$ 
        {$*PAST-DIVIDER = True}
    }
    regex rule { ^^ (.*?) (<becomes>) (\V*) $$ }
    proto token becomes {*}
          token becomes:sym<regular> { ':=' }
          token becomes:sym<output> { ':~' }
}

class RunThue {
    has %.rules;
    method slurp ($/) { 
        my @lhses = %!rules.keys.pick: *;
        my $did = False;
        my $state = $/;
        for @lhses -> $lhs {
            $state.=subst($lhs, { $did = True; %!rules{$_} });
        }
        say $state;
        samewith(self, $state) if $did 
    }
    method rule ($/) { 
        say "got rule!! ", ($0 => $2);
        %!rules{$0} = $2; 
    }
}

Thue.parse: '
1_:=1++
0_:=1

01++:=10
11++:=1++0

_0:=_
_1++:=10

---

_1111111111_', actions => RunThue.new

Some APL with lazy function application, ADTs, and a query-based compiler

As always, my title does the language perfect justice >:)

I’ve written way more about this in the readme for the language, you ought to just defer to that: https://github.com/DataKinds/apl.

DRILL

It’s a subset of Sam that I wrote in 2 days for a silly Discord game. The code can be found here, and I often come back and stare at it because it’s the best C99 I wrote this year.

A Forth, with blackjack, hookers, and row types

You wanted me to write something here? I never promised that. Here’s a discord screenshot:

I’m sorry to those who use screen readers, I am trading speed of writing this article for accessibility here. I gotta run to a NYE party after I post this, and I don’t even look cute yet. It’s kind of messed up if you really think about it.

Here are the two links from the screenshot. Good stuff!

• https://dl.acm.org/doi/pdf/10.1145/3290325
• https://thunderseethe.dev/series/making-a-language/

Game Jams

I signed up for 3, produced 0 games. I need to set my sights lower next time. Bummer!

Other projects!

Lil’ Weirdo

Crap, everyone’s doing AI! Good thing I did it first. Predating character.AI, Sora, Meta’s fake girlfriends, or that one other discord bot that got banned for endagering kids, I present Lil Weirdo.

Lil Weirdo will keep a configurable message log in its special little brain, and it’ll use that message log in order to either insult or aggresively try to flirt with other users. Because it also remembers the messages that it previously sent, it usually ends up going all tsundere on you.

It can do a handful of other things too, like generate random video game achievements or random crafting recipies. I think I honed in the prompts pretty well, check them out here: https://github.com/DataKinds/lilweirdo/blob/main/src/templater.py#L81-L508.

It’s also set up to only use locally run LLMs through Ollama (which I think is adware now, so I gotta find something else).

Media I’ve consumed!

Over the last few months I have felt my attention span return to me like a corpse-carrying eagle descending from the sky. It splays out its bounty – a ton of paperbacks.

I’ve been super into horror and sci-fi. Bird Box by Josh Malerman was great. Didn’t breathe the whole time. Three Body Problem by Cixin Liu was killer and I’m reading the second one now. I re-read There Is No Antimemetics Department by qntm.

I’m also gaming. Deadlock has been a godsend this year – finally, a good MOBA that isn’t League of Legends or DOTA 2! I love how they blended the chaos of hero shooters with the chess-ness of MOBAs. This year was another great one for roguelikes: Megabonk, Ball X Pit, and Risk of Rain 2 all had their moments.

Thank you!

Thank you to all who read this site, thank you to the friends I’ve made on Discord, and thank the stars that we are afforded another beautiful year. Life would not be as rich without any of this fun stuff to talk about. See ya 2025, happy 2026!

The Advent of Code is cool, but a lot, and not everyone’s jam. The December Adventure is low key. The goal is to write a little bit of code every day in December.

How?

Pick a project, or projects and work on them a little bit every day in December.

Day 2 (12/2/24)

Got this page set up and did a little brainstorming for what I want to work on this month. I know that there are two things off the top of my head I wanted to hammer out:

• I wanted to get an 88x31 badge set up for my website, along with a little area to display others’ 88x31s. yui asked me last month and I still have not bothered…
• I want to work more on Rosin – specifically, fleshing out the pattern variables to allow any variable to specify its eagerness, and adding syntax for rewriting a global state on top of the s-expr rewrite pointer. Something like

(; $comment) ~> 

(; (This rewrite has no state attached))
hello ~> world

(; (This rewrite only runs if there's a `ready` in the global bag))
hello |ready|~|done| world

(; (So we need new syntax for "lambda rules", rules which only run once. We use a backslash in place of the tilde.))
(; (Here's a "lambda rule" which adds a `ready` to the bag. The following rules are equivalent.))
\|ready|
||\|ready|

DAY 2 UPDATE 1: I ended up finishing a pretty good majority of the refactor that was required to flesh out pattern variables in Rosin! Check out the big ol’ git diff here.

Day 3 (12/3/2024)

I may or may not have stayed up past my bedtime working on Rosin… I’m passing all my regression tests on the new pattern variable branch!! Now we can swap eagerness on and off on all variables, even special accumulators. Tomorrow (today, after a sleep) I should write some more regression tests, for the pack/unpack accumulators and for the universal eagerness switch.

On the left, some of my regression tests. On the right, my passing test dashboard!

UPDATE 1: it’s 10:18pm, I just finished up a minor redesign of my site. Hopefully this color scheme is easier to read, and the header is no longer the size of the screen + it’s no longer begging for your attention. The mobile version of the site was also improved, so it should no longer be impossibly narrow on narrow screens. Let me know how it works!!

Update 2: Merged in my pattern variable refactor in Rosin and that simplified things nicely. I also split apart the regression tests to make them stop sharing state and updated the readme to reflect the new syntax.

Day 4

You know, I really don’t have to put the dates on the headings of each of these entries.

Today I worked a bit more on souping up the tests in Rosin. I made tests be printed to standard out instead of requiring the compiler to output the final state. I also separated all the test files into multiple different files so they run in their own contexts.

All of this makes running tests quite nice. The Makefile lets me run specific sets of tests too.

I also fixed some (but not all) bugs with the accumulators I uncovered while writing extra tests. For example, the Pack and Unpack accumulators don’t work quite how I want them to. They don’t quite walk the s-expression fully and it’s quite buggy.

((pack ?@) ~> ?@)
(pack (this (is a (strangely) nested) list)) 
 --- became --- 
(this is a) 

I’ll have to deal with that soon. For something I fixed… turns out if you matched multiple values against the negate accumulator, they’d all come back backwards.

((negate ?- ?- ?-) ~> ?-)
(negate 1 2 3) 
 --- became ---
(-3 -2 -1)

That’s fixed now. Progress!

Day 5

Didn’t do a lot of coding today. Between moving, work, and having a house guest over tonight I simply wasn’t sitting at the computer for very long.

I got about an hour to myself. I started thinking a bit about setting up a runtime state abstraction in Rosin. This will let me add a multiset bag, support one time lambda rules, and set up a better more explicit ordering for how rules are ingested and then applied.

My changes are still very preliminary, I posted them up onto a separate branch.

For background entertainment, I was watching this today:

Day 9

Whew. I am sorry for the lack of updates, but the last couple of days flew by. On the 6th and the 7th, my partner and I were going back and forth to the house we’re moving into. On the 7th and 8th our power was out. To be more specific: the power was out in exactly half of our unit – and my computer’s outlet was unfortunately affected. All the while I have work and other shenanigans that get in the way. Le sigh… we cringe on…

I worked on Rosin a little bit tonight. I fixed a bug in the new tree zipper datatype where moving the zipper down to the first child would reverse the right hand side of the context. I suppose it made sense at the time but hindsight is 50-50 and I cursed my past self. So the zipper works correctly now which is pretty cool. It worked well enough so I merged the zipper into main :3

I have been listening to a lot of Remi Wolf.

Day 10

Rosin progresses little by little. You can now define single use rules with ~, like so:

$ rosin -p
(/evil/ ~ "$<good$>") "the evil wizard" "the evil tower"


+-----------------+
| Final transform |
+-----------------+
"the good wizard"
"the evil tower"

So that will definitely allow for some fun stuff.

I want to start writing more interesting programs in Rosin, but I keep going down development rabbitholes. The final rabbithole is nearing its conclusion: I have hashed out how I want multiset state rules to look. You will be able to interact with the multiset bag on the rewrite head with the (:needs | :gives) pattern. The same function that matched ~> rules WILL SOON know how to match all variations of these | rules… but it’s not quite there yet.

$ rosin-can't-do-this-quite-yet -p

(|(apple pear orange peach)) puts an apple, pear, orange, and peach into the bag
(apple |) takes an apple out of the bag
(apple |) doesn't match a second time 

+-----------------+
| Final transform |
+-----------------+
puts an apple, pear, orange, and peach into the bag
takes an apple out of the bag
(apple |) doesn't match a second time

Both sides do not need to be specified. | indicates a multiset matching rule that will only run once, and |> rules will run ad infinitum.

( (pear apple grape peach) |> ((fruit salad)) )
now the combination of pear, apple, grape, and peach will always become (fruit salad)

Wait, I heard you say: (fruit salad)? Like, you put an S-expression into the multiset? Heck yeah I did! The full range of Rosin values can go into the multiset and this means we’ll be able to hijack the pattern variable machinery to do some very cute things:

( (sword (stone :name)) | ((sword :name)) )

( | (stone "King's stone"))
( | sword)
will produce one thing in the bag: (sword "King's stone")
a sword's strength is derived from its legendary name

Last but not least – you’ll be able to devise a rule that only matches the S-expression tree when something is in the multiset bag. Or a tree rewrite rule that adds something into the bag. The & symbol will be able to combine a multiset rewriting rule with a tree rewriting rule, such that the combined rule only matches when both conditions are satisfied. This has some crazy potential imo, and I just nailed down the syntax tonight:

(| n & hello ~> world) 
produces an n to the bag every time it matches `hello`

(n n | m & (; :comment) ~>) 
limits the amount of comments you can write to half the `hello`s you write... better be polite!

Some of this is implemented, some of it isn’t… but I feel good having this all theorycrafted and the way forward from here seems clear to me.

Day 11

Only posting a quick update today because I want to head to sleep early!!

A few new Rosin updates for ya….

I added a new regression test for the multiset state:

(Test a "Plain terms can be parsed and consumed"
    Given (
        ((pomme pomegranate) |> weird-fruit-salad)
        (|pomme)
        (|pomegranate)
        (|(pomme pomegranate))
        (weird-fruit-salad|)
        (weird-fruit-salad |)
    )
    We expect ())

I finished setting up the consumption of rules with multiset action, see recognizeDef. So Rosin will now really recognize and consume all these forms of rules:

(pattern ~> template) a tree rewriting rule
(pattern ~ template) a one time tree rewriting rule
((things i want) |> (things i will get)) a multiset rewriting rule
((things i want) | (things i will get)) a one time multiset rewriting rule
(want | get & pattern ~ template) a one time combined tree+multiset rewriting rule
(want | get & pattern ~> template) a combined tree+multiset rewriting rule

Note that the shortened forms from the regression test (like (weird-fruit-salad |)) won’t currently work.

Very soon Rosin will be able to apply tree rewrite rules conditionally based on the state of the multiset, but for now I left a hole in the function where it will be filled with dedicated Multiset methods. Soon. I’m so close to having this working.

-- Filters a list of defs down to only those which are satisfied by the current state of the multiset
filterByMultiset :: Monad m => [EatenDef] -> RuntimeTV m [EatenDef]
filterByMultiset defs = do
    pocket <- gets runtimeMultiset 
    pure $ filter (ok pocket) defs
    where ok ms = undefined

For anyone still reading, thanks for sticking with me on this journey. I have really been looking forward to writing these entries every night.

Day 15

I spent the day today on the phone with banks and electricians making preparations for the new house. A few days ago my partner and I hosted a packing party. All of our friends came over, ate pizza, and put our belongings into boxes. Progress on my blog or projects has taken a bit of a backseat to moving.

All that being said, I worked on Rosin a bit more tonight!

There is a full fledged Multiset type now. All I’ve got implemented is reading things out of the multiset but putting things in will come soon enough.

module Multiset where
import qualified Data.Map as M
import Control.Monad (foldM)


newtype Ord a => Multiset a = Multiset { unmultiset :: M.Map a Int } deriving (Show)

fromList :: Ord a => [(a, Int)] -> Multiset a
fromList = Multiset . M.fromList

toList :: Ord a => Multiset a -> [(a, Int)] 
toList = M.toList . unmultiset

empty :: Ord a => Multiset a
empty = Multiset M.empty

null :: Ord a => Multiset a -> Bool
null = M.null . unmultiset

-- Is this element inside the multiset in a sufficient quantity? 
inside :: Ord a => (a, Int) -> Multiset a -> Bool
inside (x, n) = maybe False (n <=) . M.lookup x . unmultiset 

-- Are these elements inside the multiset in a sufficient quantity? 
allInside :: Ord a => Multiset a -> Multiset a -> Bool
allInside xns ms = all (`inside` ms) (toList xns)

-- Take out this many copies of this element from our multiset, if we can!
grab :: Ord a => (a, Int) -> Multiset a -> Maybe (Multiset a)
grab xn@(x,n) ms = if inside xn ms then Just . Multiset . M.adjust (subtract n) x . unmultiset $ ms else Nothing

-- Take out this many copies of these elements from our multiset, if we can!
grabMany :: Ord a => Multiset a -> Multiset a -> Maybe (Multiset a)
grabMany xns ms = Multiset <$> foldM (\m xn -> unmultiset <$> grab xn (Multiset m)) ms' xns'
    where ms' = unmultiset ms; xns' = toList xns

The Rosin runtime now checks that the multiset is satisfactory for any given function before using it to rewrite. Check out that sick ass runtime:

-- Filters a list of defs down to only those which are satisfied by the current state of the multiset
filterByMultiset :: Monad m => [EatenDef] -> RuntimeTV m [EatenDef]
filterByMultiset defs = do
    pocket <- gets runtimeMultiset 
    pure $ filter (ok pocket) defs
    where 
        ok :: MS.Multiset (Tree RValue) -> EatenDef -> Bool
        ok ms def = MS.allInside (defWantsFromBag def) ms

-- Carry out one step of Rosin's execution. This essentially carries out the following:
--   1) We check for a definition at the current rewrite head and ingest it if there's one there
--   2) We try to apply our rewrite rules at the current rewrite head
--   3) We move onto the next element in the tree in DFS order. If we're at the end, we loop back to the start
-- Gives back (the amount of rules applied, whether we jumped back to the top of the tree). 
runStep :: RuntimeTV IO (Int, Bool)
runStep = do
    verbose <- gets runtimeVerbose
    -- Begin 1
    eatDef 
    -- Begin 2
    -- Apply single use tree rewriting rules
    -- !!! ===== We check the multiset here!!! Take a look....  ===== !!! --
    defs <- gets runtimeSingleUseRules >>= filterByMultiset
    maybeTreeRewrite <- applyTreeDefs defs
    when (isJust maybeTreeRewrite) $ do -- A single use rule matched once, we gotta delete it!
        let (Rewrite patternToDelete _) = fromJust maybeTreeRewrite
        modifyRuntimeSingleUseRules (filter (patternDefEq patternToDelete))
    -- Apply multi use tree rewriting rules
    -- !!! ===== We check the multiset here again!!! Wow!!!!!  ===== !!! --
    defs' <- gets runtimeRules >>= filterByMultiset
    maybeTreeRewrite' <- applyTreeDefs defs'
    -- Begin 3 (I Love Laziness)
    newZipper <- gets (Z.nextDfs . runtimeZipper)
    modifyRuntimeZipper (const newZipper)
    when verbose (lift $ print newZipper)
    -- Give back the value we use to assess termination
    atTop <- gets ((== []) . Z._Ups . runtimeZipper)
    pure (sum $ maybe 0 (const 1) <$> [maybeTreeRewrite, maybeTreeRewrite'], atTop)
        where
            -- True if the EatenDef has the same pattern as the tree
            patternDefEq :: Tree RValue -> EatenDef -> Bool
            patternDefEq pat1 def = case defToRewrite def of
                Nothing -> True
                Just (Rewrite pat2 _) -> pat1 /= pat2 

Sorry. Maybe it’s rude to throw a huge block of code at you at once. I ought to be more polite.

Anyways, Rosin will now refuse to match a rule if the multiset state is insufficient. Look!

$ cat sample/small.tree; rosin -p sample/small.tree 
(fruit-salad | () & hello ~> world)
(1 2 3 hello 4 5 6)

+-----------------+
| Final transform |
+-----------------+
(defined "Multiset {unmultiset = fromList [(fruit-salad,1)]}| & hello ~> world")
(1 2 3 hello 4 5 6)

So that’s that. Hope you enjoyed! Next time maybe we’ll go less heavy on the Haskell and heavier on the Rosin. Talk to you soon!

Day 16

Tonight cost me a lot of my sanity and I will inevitably be gluing back together the pieces of my sleep-deprived codebase later.

That being said… Rosin now has full support for rules which interact with multiset state. It’s done oh my god it’s done. Done enough to start writing tests for and to start making more informed decisions on structuring the codebase. They don’t do anything fancy like match against regex but that can all happen soon. We have a foundation in place to build off of!

$ cat sample/poc.rosin; rosin -p sample/poc.rosin 
(| pear)
(| pear)
(| pear)
(| orange)

(@ bag)

((pear pear) | pear-salad)

(@ bag)

+-----------------+
| Final transform |
+-----------------+
((orange 1) (pear 3))
((orange 1) (pear 1) (pear-salad 1))

What’s (@ bag), you may ask? That’s a builtin! This particular builtin writes out the current state of the multiset bag.

There are a couple of builtins hanging around now. Most notably (@ parse :str) which parses a string into a Rosin tree, and (@ cat :path) which loads another file as a string. These together make my test files prettier.

((p ?>) ~> ?>)
((t :desc :!got :wanted) ~> (p (❌ :desc got :got wanted :wanted)))
((t :desc :!val :val) ~> (p (✅ :desc :val)))
((Test a :desc Given :test We expect :val) ~> (t :desc :test :val))

(Test a "Lambda rule"
    Given (((fruit basket) ~ apples oranges pears dragonfruit) 
           (fruit basket) 
           (fruit basket)) 
    We expect (apples oranges pears dragonfruit
               (fruit basket)))

(Test a "Confusing named rule"
       Given ((once ~ once once) once) We expect (once once))

now becomes

(@ parse (@ cat "t.rosin"))

(Test a "Lambda rule"
    Given (((fruit basket) ~ apples oranges pears dragonfruit) 
           (fruit basket) 
           (fruit basket)) 
    We expect (apples oranges pears dragonfruit
               (fruit basket)))

(Test a "Confusing named rule"
       Given ((once ~ once once) once) We expect (once once))

which is way cuter if I do say so myself.

More to come soon!

Day 17

Nothing today. I played through a cute little game called Digseum after work tonight.

It was absolutely adorable. Worth the $2 and quite satisfying to boot.

There is a lot of precedent for how to maximize the value of your time when you ask questions online. “Don’t ask to ask” and (perhaps more humorously) Cunningham’s Law are what immediately comes to my mind in this context. There is much less precedent for how to answer questions – or even why we choose to spend our time answering questions online.

Eric S. Raymond has written at length about asking good questions¹ and yet left the “How To Answer Questions in a Helpful Way” section stunted at 9 suggestions. Stack Overflow is the same: the page describing how to ask questions is rich with direct suggestions on how to make the best use of your time asking questions. Most of the given advice is generally applicable to any development forum with tags and post titles. The page describing how to answer them is about half the length and full of softer advice dedicated to SO’s specific position as a community question-archival site: writing with good grammar, providing context to avoid link bitrot, using the bounty system to ask someone to continue your partial answer.

There is an asymmetry here. Advice given to question-askers involves getting the most value out of the time you and the community spend on said question. This is ultimately the goal of the asker: to learn, to gain value from the question at hand. Contrast this with advice given to question-answerers, which is more scatter-shot and generally revolves around producing a satisfactory answer. This is unmotivating as this is ultimately not the goal of the answerer! I claim, supported by the text above, that there are really two reasons someone would want to answer questions:

1. To learn.

   Common knowledge dictates that one does not understand something if they cannot explain it. Explaining things online is a fantastic way to find one’s own knowledge blind spots; collaborative problem-solving gives a very low-risk opportunity to dive deeper into topics just outside of one’s reach.

   Learning also happens at a community level. Raymond notes that a helpful answer will “[h]elp your community learn from the question. When you field a good question, ask yourself ‘How would the relevant documentation or FAQ have to change so that nobody has to answer this again?’ Then send a patch to the document maintainer.”.

2. To grow their community.

   Raymond notes that “[Hackers] like answering questions for people who have demonstrated they can learn from the answers”. A person who grew after interacting with a community is going to come back for more. This is a positive feedback loop, and it’s multiplied by the near-realtime responses and casual atmosphere given by platforms such as Discord or IRC. Strong learners with interesting, insightful, novel questions make for great community members!

I am excluding any communities that set up gamified or otherwise perverse objectives to encourage participation (upvote this post if you agree!)

This brings me to my ultimate point: how do we maximize these incentives as question-answerers? What can we do to go above and beyond producing helpful answers, making the time we spend answering more valuable to us? Here are a couple of things that I have personally found to make my time participating online more valuable:

The great, nonexhaustive framework for online participation

• Use realtime platforms to your advantage
  • As mentioned above, instant messaging platforms allow for instant feedback between question-askers and question-answerers. Many of the concerns about asking good questions come from a time of email lists and traditional forums, where a lack of information in the original post could take days to be rectified. Over Discord, getting clarifications from askers is often a matter of minutes. This drastically limits the frustration and wasted time associated with badly-framed questions.
  • The conversational nature of chat platforms allows troubleshooting and stating a problem space to naturally become brainstorming. This is not the case on Q&A platforms, for example, as there is a strict distinction between “question” and “answer”. Intermediate brainstorming and conversation is relegated to a comments section or a secondary chat room. On an IM platform this distinction does not exist – to maximize learning, one must take advantage of this.
• Assume good faith
  • This is the titular “stop asking what, start asking why”.
    • Bad actors or low-effort posters in online communities are inevitable. That being said,
    • I have seen enough instances in programming communities where someone will come in with a conversational style or set of ideas that resemble bad-faith posting. They’ll use ALL CAPS or a twyping qwirk or send / messages / with / one / word. They might be stubborn or rash or stuck on their own ideas.
    • These posters often present some of the most unique ideas available, and I have found that engaging can often maximize learning (sometimes at the cost of frustration). As a question-answerer, maximizing learning mandates that one must assume good-faith in these situations and dig into the “why”s of their choices rather than being stuck on the “what”s of their possibly absurd current situation. This does often require skill in analyzing XY problems.
  • Assuming a given person is a bad actor is a losing-sum game. Consider the cases:
    • A good-faith question is met with an assumption of good-faith ➡️ everyone is happy, the question may get answered
    • A bad-faith question is met with an assumption of good-faith ➡️ either the asker improves their question, gets bored and leaves, or they escalate, at which point you can disengage
  • Or, on the contrary:
    • A good-faith question is met with an assumption of bad-faith ➡️ a potential community member is turned away
    • A bad-faith question is met with an assumption of bad-faith ➡️ time is saved as you may disengage immediately
  • To maximize community growth, we must therefore assume good-faith to avoid turning away potential community members.
  • To maximize learning as a result of these interactions, we must consider that nothing is learned upon turning away community members or immediately disengaging with bad-faith questions. Something may be learned if the is answered or if the badly-posed question is improved. Attempting to assist with the low-effort poster’s issue may give the answerer an opportunity to gain a deeper knowledge of the system being badly asked about.
  • Efficient moderation allows active community participants to more effectively gauge when to disengage with an actual bad actor, minimizing the time wasted.
• Address XY problems through risk analysis
  • To address an XY problem, one must first learn to identify an XY problem.
    • Look for questions where the asker wants to know how to carry out a task using tooling that isn’t made for that task
    • Look for questions where the asker insists there is only one way forward
    • Look for questions where the asker thinks a process is supposed to work.
  • Address the problem fully if you choose to address it. Ask the asker what they’re trying to accomplish instead of entertaining their solution. Note that they only see trees where you may see the forest. Learn from the aspects of the situation that they’ve missed, and consider if there are any similar workflows that you have that are suffering from the same blind spots.
  • Raymond states the fundamental point well: “If you’re going to answer the question at all, give good value. Don’t suggest kludgy workarounds when somebody is using the wrong tool or approach. Suggest good tools. Reframe the question.”
• Askers must answer. Answerers must ask.
  • To maximize learning, you must be willing to have a conversation!
  • Make use of the resource that other question-answerers provide.
  • There must be no hierarchical distinction between those who ask and those who answer in a community. Maximization of learning requires that everyone is comfortable to both seek knowledge and to share their subset of knowledge.
    • The effect where longer standing members of a community are afforded more technical weight than newer members needs to be explicitly considered when the goal is the breakdown of hierarchy.

I hope that you’re able to get something out of the suggestions I’ve made above. If not, hopefully the reframing of online discussion as something potentially valuable encourages you to go out and participate :)

The original title of this was to be “From Context to Cptr: Bare Bones Game Development in Haskell”. I will let 2019 me take it from here.

I got into programming when I was 8 because I wanted to make games. I guess, deep down, I was never truly able to satiate that desire. I’ve never released a game, I’ve never completed a game, and hell – I’ve never gotten far enough to even draw up assets for a game.

But I ran into a library yesterday called Raylib that kind of rekindled the playful fire that lived deep down under my pragmaticism. Raylib lives at https://www.raylib.com/. I immediately fired up VS Code and hammered out some C for the first time in two or three years. Suffice to say, I had fun. Not fun like “wow, this code is elegant,” or fun like “wow I’m making a lot of money doing this,” but fun like “I’m giggling at the screen because I made a circle bounce back and forth.”

And that was an incredible feeling.

So, in the spirit of all things good: if it’s worth doing, it’s worth overdoing. That’s why I’m writing this blog post.

This won’t be like any other blog post that I’ve written. I am writing this post live as I’m experimenting with building a game from the bottom up in Haskell. You’ll see every single decision I make, and everything I find exciting enough to share, even if I go back on it five minutes later. No game frameworks, no library bindings – just me, Stack, a fresh install of GLFW, and a readiness to get hacking.

In one window, I have my blog post. In the other window, my code. Without further ado…

9:23 PM, day 1

I came up with the idea and started writing this blog post.

11:19 PM

Finally got around to initializing the stack project!

12:57 AM

Here’s my first attempt at defining enough of a wrapper around GL and GLFW in order to run the example code on the GLFW documentation page. This is before I’ve even tried compiling it, so this is pre-iteration-1:

GLFW.hs:

{-# LANGUAGE ForeignFunctionInterface #-}

module GLFW where

import Control.Monad

-- | Init functions
foreign import ccall "glfwInit" init :: IO Int
foreign import ccall "glfwTerminate" terminate :: IO ()

-- | Window functions
data Window = InternalWindow deriving (Storable)
foreign import ccall "glfwCreateWindow" createWindow :: Int -> Int -> CString -> IO (Ptr Window)
foreign import ccall "glfwWindowShouldClose" _windowShouldClose :: Ptr Window -> IO Int
windowShouldClose :: Ptr Window -> IO Bool
windowShouldClose = fmap (0 /=) . _windowShouldClose
foreign import ccall "glfwSwapBuffers" swapBuffers :: Ptr Window -> IO ()
foreign import ccall "glfwPollEvents" pollEvents :: IO ()

-- | Context functions
foreign import ccall "glfwMakeContextCurrent" makeContextCurrent :: Ptr Window -> IO ()

GL.hs:

{-# LANGUAGE CPP, ForeignFunctionInterface #-}

module GL where

#include <GL/gl.h>

data ClearMask = COLOR_BUFFER_BIT | DEPTH_BUFFER_BIT | STENCIL_BUFFER_BIT
foreign import ccall "glClear" _clear :: Int -> IO ()
clear :: ClearMask -> IO ()
clear COLOR_BUFFER_BIT = _clear GL_COLOR_BUFFER_BIT
clear DEPTH_BUFFER_BIT = _clear GL_DEPTH_BUFFER_BIT
clear STENCIL_BUFFER_BIT = _clear GL_STENCIL_BUFFER_BIT

1:08 AM

Turns out including header files in Haskell isn’t as easy as using #include <GL/gl.h>.

6:38 PM, day 3

After a day long break where I was busy with some freelance work, I came back to this project and finally made some progress! After fixing some linker errors a couple Haskell bugs…

We have a window!

Interlude: Why Haskell?

I believe that the monadic approach to programming, in which actions are first class values, is itself interesting, beautiful, and modular. In short, Haskell is the world’s finest imperative programming language.

from https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/mark.pdf.

I didn’t want to do this in C because C is the language that can directly interface with GLFW and OpenGL. I didn’t want to be able to do this because I wanted a reason to sit and ponder each function before I use it. Having to write sensible bindings for every single graphics function that I use encouraged me to take this time.

So the question remained of what langauge I should decide to use. I could have went with a run-of-the-mill scripting language, but something about the elegant abstractions of Haskell drew me toward using it for this project.

For one, Haskell is my favorite language, so it’s naturally one of my top choices for anything that I do. But further than that, the biggest roadblock that I hit trying to learn OpenGL the first time a while back was the difficulty of composing abstractions on top of the admittedly obtuse graphics pipeline. Haskell is notorious for being able to abstract. So abstract I shall.

11:53 PM, day 3

Started reading through https://learnopengl.com/Getting-started/Hello-Triangle. Buffers make a lot more sense than I remember them making.

as you can see, the blog looks different!

it used to look like this

it was themed after stardew valley. it was cute and i liked it a lot. The reasons I decided to give it a visual overhaul are as follows:

• I didn’t know where to put other pages without it looking bizarre,
• I’d like to write more long form content about video games and I felt like having my page themed after a single game is a lil biased, and
• I didn’t feel like touching up the background lol

I had a few goals with this redesign

• Keep it quirky
• Keep it readable for old posts (including adding some extra goodies like syntax highlighting)
• Giving myself space to add more pages and do further experimentation

I suppose this also counts as part of my 100 blog posts challenge, but I’m no longer numbering the titles because that was annoying lol

so, with this redesign I’ve given myself a good foundation to keep hacking away on. hope you like it! new long form posts and possibly other goodies soon…

* wan = 1
* tu = 2
* luka = 5
* mute = 20
* ale = 100

jan li toki e nimi “tu tu” la mi kute li sona e nanpa 4. jan li toki e nimi “tu wan” la mi sona e nanpa 3. jan pi mute suli a li sona sama. mi toki lon ilo Siko kepeken nasin ni la jan li sona e nanpa mi.

nasin ni li pona lukin. taso, o lukin tu. mi wile toki e nanpa 99. nasin ni la nanpa 99 li sama nimi “mute mute mute mute luka luka luka tu tu”. ni li suli ike a! mi wile ala toki e ni. mi toki e ni la jan li ken ala sona e nanpa 99. jan li kute e “… mute, mute, mute, …”. ni li pakala e lawa.

mi toki e nimi “luka wan” la jan li sona e nanpa 6. sama la jan Loman li sitelen e nimi “VI” la jan Loman ante li lukin li sona e nanpa 6. jan Loman li ken sitelen kin e nimi “IV”. jan ante li lukin e nimi “IV” la ona li sona e nanpa 4. taso… mi ken ala toki e nimi “wan luka”. mi tawa e nimi “luka” lon monsi pi nimi “wan” la jan li ken ala sona e nanpa 4. jan li sona e nanpa 6, anu, jan li sona e ijo “wan” pi mute 5. mi wile pana e sona pi nasin nanpa Loman ni la mi wile kepeken nasin ni a.

nasin nanpa Loman li wawa. mi wile toki e nanpa 99 la mi ken toki lili kepeken nasin ni. o lukin! nanpa 99 li sama nimi “wan ale” kepeken nasin ni. nimi “wan ale” li pakala ala li suli pona. kin la nanpa 4 li sama nimi “wan luka”.

lawa pi nasin nanpa Loman li pona (sama toki pona, tawa mi). ni la toki pona li wile e nasin nanpa la toki pona o kama jo e nasin ni. lawa pi nasin nanpa Loman li ni:

1. nanpa lili li lon monsi pi nanpa suli la o wan e ona. o lukin: nimi “luka (suli) wan (lili)” li sama nanpa 5 + 1 = 6.
2. nanpa li lon monsi pi nanpa sama la o wan e ona. o lukin: nimi “luka luka (sama)” li sama nanpa 5 + 5 = 10.
3. nanpa suli li lon monsi pi nanpa lili la o pakala e nanpa suli kepeken nanpa lili. o lukin: nimi “luka (lili) mute (suli)” li sama nanpa 20 - 5 = 15.

lawa ni li lawa ale! mi toki e ni: nasin nanpa Loman li pona li wile lili e wawa sina. nasin ni li pona e nanpa. mi pilin e ni: nasin nanpa Loman li kute e nasin pi toki pona.

o tawa! o musi! o toki!

jan pi wile sona li toki tawa mi e ni: “sina toki kepeken toki pona tan seme? jan seme li toki sama?”.

mi toki e ni: “mi toki kepeken toki pona tan ni: ona li musi. kama pi sona toki li pona tawa mi.”

taso, jan pi wile sona li toki e ni: “sona pi toki pona li sona pi toki ala. sina o kama sona e toki lon.”

mi toki e ni: “toki pona li toki lon ala lon?”

jan pi wile sona li toki e ni: “toki pona li lon ala. sina o kama sona e toki Tosi e toki Sonko e toki Epanja. sina ken ala esun kepeken toki pona. “

mi toki e ni: “mi wile ala esun. ante la toki pona li ken pana e sona pi toki ante tawa sina. taso, ni li pana e sona ala la ni li awen pona.”

ijo suli

ijo suli li ni: toki pona li musi. jan mute li toki e ni: “mi o kama sona e toki pona tan seme?” taso, toki pona li musi ala tawa sina la sina o kama ala sona e toki pona. tan ante li lon ala. musi li ale.

“musi li ale” li nasin wawa. jan mute li toki lawa e ni: “toki pona o wan e jan ale. toki pona o toki International Auxillary Language!” taso, ni li pakala e nasin wawa. toki IAL li musi ala! nasin pi wan e jan ale li musi ala! mi toki tu: toki pona li musi ala tawa jan la jan o kama ala sona e toki pona. taso, toki IAL li pona la toki IAL li wile e ni: jan ale li ken toki lon ona. ona li pona (jan ale li toki e ona) la jan mute li wile ala toki lon ona li musi ala toki. ni li ike suli. mi ale o kute e nasin wawa.

ante la kulupu pi toki pona li pana e pona mute tawa jan ale. jan suli li toki wawa e ni: “kulupu suli li ken ike”. ni li lon lili, taso, nasin wawa li ken awen e pona pi kulupu ni. kulupu li suli la toki pona li musi tawa jan ale kulupu la kulupu li awen pona. mi toki tu: musi li ale.

pini musi

jan pi wile sona li toki e ni: “sina ken ala toki tawa jan lon linluwi ala.”

mi toki e ni: “sina ken ala toki tawa mama sina lon linluwi ala. mi en mama sina li toki lon tenpo pimeja ale.”

jan sin li toki sona e ni: “nimi ‘pi’ li sama ala sama nimi ‘of’ lon toki Inli?”. jan sona li toki e ni: “ala”.

kin la jan sin li toki sona e ni: “mi ken ala ken ante pi toki Inli e nimi ‘toki’ tawa nimi ‘talk’ [anu nimi ante…]”. jan sona li toki e ni: “ala”.

ni li nasin pona. taso… ona li sama ala tan seme? sina ken ala ante tan seme? mi pana e sona ni lon lipu ni.

ijo wan li ken weka e len sona la ijo wan li ni:

nimi ale li jo e poki kon.

poki kon li seme? o lukin:

mi sitelen e nimi “tomo” lon poki kon ona:

lon la poki kon ona li jo e ijo mute. mi ken sitelen e ijo:

mi ken sitelen e nimi ante e poki kon ante:

o lukin! nimi “tomo” en nimi “building” li jo e sitelen sama. mi ken wan e ni tu:

taso, mi ken ala wan e sitelen ale pi nimi “tomo” e sitelen ale pi nimi “building”. nimi “building” taso li jo e sitelen pi jan pali. kin la nimi “tomo” taso li jo e sitelen pi tomo telo e sitelen pi tomo lape.

nimi “tomo” li sama ala nimi “building” tan sitelen ni. poki kon ni tu li jo e sitelen ante.

mi ken sitelen e poki kon mute ante. taso, poki kon ante li ken ala sama poki kon pi nimi “tomo”.

nimi “bedroom” li lon insa poki kon pi nimi “tomo”. ni li wawa tan ni: bedroom ale li tomo. (taso, tomo ale ala li bedroom).

ijo ale li toki e ni: nimi “tomo” li ken sama pi nimi mute. nimi mute ni li lon poka poki kon pi nimi “tomo”.

sina sitelen e poki kon ale la sina pali e jaki. nanpa sitelen li suli ike. nanpa pi poki kon li suli ike. nimi li wawa!

mi wile e ni: sina pilin pona li pilin lawa wawa.

o pona tawa:

• sitelen tan linluwi https://www.flickr.com/photos/brent_nashville/4645745968 CC BY-NC 2.0
• sitelen tan linluwi https://commons.wikimedia.org/wiki/File:Bed_Room.jpg CC BY-SA 4.0
• sitelen tan linluwi https://commons.wikimedia.org/wiki/File:Construction_workers.JPG CC BY-SA 3.0
• jan Ki lon ma pi kama sona. ona li pona e toki ni.