Because Toki Pona has a limited number of words, and few of them are actually related to programming, I have to be selective about which ones I use to mean certain things. I encountered a key example in March when I realised that I couldn’t use anu to mean both “else” in a conditional statement as well as “or” in a Boolean operation, because there was no way to disambiguate the two.

Instead I decided to use “a” for the conditional statement. In Toki Pona, “a” is a general-purpose exclamation. Here it’s being used to represent an interruption to what was expected. These are the kinds of concessions I’m making as I map Toki Pona words to Poki Nanpa functions.

Another concession is that I’ve scrapped the idea of having no brackets. You can still write a program just fine without them, but they make functions a lot more concise and make it a bit clearer to tell what’s going on. I considered using Toki Pona words to mark the beginning and end of a bracketed segment instead, but decided against this because there was nothing that would have worked grammatically. For example, I could have used pini (“finish”) to let the programmer indicate when a block is done. But reading that as a grammatical sentence in Toki Pona would apply the adjective “finished” to whatever expression it followed, which usually doesn’t make sense. In the end, brackets ended up being the most elegant solution.

Toki Pona itself, like English, has the kinds of grammatical ambiguities that a programming language can’t handle if you want it to do the same thing every time you run it.