The kcats Programming Language

Here we create a generator of the infinte fibonacci sequence, and collect the first 20 results.

[1 0                ;; start with the first two numbers
 [[+] •🛡️ ▶️ 🔀 👥] ;; add the two numbers but only consume the first one,
                    ;; then copy the result  
 🔳 🔳 [🔀] 🪆      ;; create a recurrence 
 20 taker           ;; limit the generator to 20 items
 collect]           ;; collect the results into a list
reap                ;; discard leftover state, keeping result

[1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 4181 6765]

Find highest priced of all products rated 4.5 or higher, and in stock

[[[name "Mouse"] [price 50] [rating 4.4] [inStock ✔️]]
 [[name "Laptop"] [price 1000] [rating 4.7] [inStock ✔️]]
 [[name "Desktop"] [price 1500] [rating 4.9] [inStock 🔳]]
 [[name "Tungsten Cube"] [price 2500] [rating 3.4] [inStock ✔️]]
 [[name "Keyboard"] [price 70] [rating 4.8] [inStock 🔳]]
 [[name "Monitor"] [price 200] [rating 4.5] [inStock ✔️]]
 [[name "Camera"] [price 600] [rating 4.3] [inStock ✔️]]]

;; keep only rating >= 4.5 AND inStock
[[[[[rating] lookup 4.5 >=] 
   [[inStock] lookup]]
  [🛡️ ▶️] 💯 ▶️ •🗑️] keep

 ;; find the remaining product with highest price
 [[[price] lookup] max-by] fold] assemble

[[name "Laptop"]
 [price 1000]
 [rating 4.7]
 [inStock ✔️]]

Kcats is designed to require learning as few concepts as possible. It's made with:

• Stacks
• Data values (numbers, strings, bytes)
• Lists
• Functions
• Pipes

All of these are combined in various ways to achieve any type of expression, the same way a few types of lego bricks can be combined to make any object.¹

Kcats code is just english words, pictographs (aka emoji), quotation marks, [ and ]. No other symbols. ²

Format code however you want, kcats doesn't care.

Interactive development is encouraged. The documentation for the standard library can be queried with the language itself. See 5.4.

Kcats' metaprogramming facilities (programs that write programs) allow you to express yourself succinctly.

There is zero ceremony. A program can easily be a single line consisting of a few words:

"contacts.txt" slurp read [[age] lookup 55 >=] 🧲  

That reads a database file of contacts, and prints only those contacts at least 55 years old. The program is 8 words.

You don't need a "main" method, or class declaration or any other boilerplate. You only need to specify what the program is actually supposed to do.

• [X] Automatic memory management
• [X] Multithreading
• [X] Error handling
• [X] Metaprogramming
• [X] Channels/CSPs
• [X] Introspection
• [X] Filesystem I/O
• [X] TCP/IP Socket I/O
• [X] Generators
• [X] Sequence library
• [X] Cryptographic primitives
• [X] Builtin debugging tools
• [X] Serialization

Kcats is meant to handle personal automation tasks, where expressivity and simplicity matter far more than raw performance. It's not currently suitable for processing huge datasets or high performance number crunching, and likely never will be.

See Using

item

A unit of information (aka value) of various types: numbers, strings, byte arrays, words, characters, and lists. (examples: 5, "Bob", swap, [1 2 3])

list

An item that contains other items, in a particular order (delimited by square braces). Example: [a "foo" 2].

program

a list of instructions intended to be carried out by a machine. (example: [[odd?] filter]).

stack

A list with a first-in, first-out interface. This is where the program stores all the data it needs to manipulate.

word

causes the program to do something, usually taking some items from the top of the stack, and using them to create new stack items. Words can be represented as actual english words, or math symbols or even emoji. (examples: 🔀, +, over)

axiom word

A word not defined in terms of other words.

definition

what a word is supposed to do, represented either in the base language for axiom words, or as a program.

dictionary

a set of available words and their definitions.

environment

the entire state of an executing program, which includes a stack, program, and dictionary.

pipe

A conduit to communicate between environments, and to the outside world. Items are put into pipes and emerge somewhere else (another environment, a file on disk, a remote machine, etc).

Kcats uses a stack to keep track of all the values it needs to work with, instead of variables and function parameters. To manipulate data, you put it onto a stack, and then words operate on the items at the top of the stack (which might remove, shuffle, replace, or add new items). If you're familiar with functions in other languages, that's all words are - they're a function of the current stack, and they return a new stack.

Here's a simple example. If we mentally execute the program below, we first put 1 onto the stack. Then we put 2 onto the stack. 2 is now on top of 1. Then we put the word + onto the stack, where it will consume the 2 and the 1, and leave their sum, 3.

1 2 +

3

Multiple steps are accomplished just by adding more words and data. For example, in the program below we can add 1 and 2 (leaving 3 on the stack), and then multiply by 5, leaving 15.

1 2 + 5 *

15

Here's how it would look step by step (where the | separates the program that hasn't run yet - on the right, from the stack on the left). The stack's top item is just to the left of the |.

;; stack |  remaining program
;; ------|--------------------
         | 1 2 + 5 * 
       1 | 2 + 5 * 
     1 2 | + 5 *
       3 | 5 *
     3 5 | *
      15 |  

When there is nothing remaining to the right of the |, the program is finished. The result is what is left on the stack (in this case 15).

Note the stack can end up with multiple items. When it's printed, it will always start with the top of the stack - the last thing in is the first thing out.

1 2 3

3 2 1

Lists are denoted with square brackets, like [1 2 3]. When encountered, they just go onto the stack as a single unit. Words can operate on lists once the list is on the stack. You can see below the word 🔗 joins two lists into one.

[1 2 3] [4 5] 🔗

[1 2 3 4 5]

You'll notice in the earlier examples there's a fair number of pictograms (emoji). Kcats uses emoji pictographs instead of english words for some commonly used functions. They are treated just like any other word, except more colorful and succinct.

To get started let's define what a few of these emoji mean, that are used in the next section.

• 🔀 swaps the top two stack items.
• ▶️ executes a program snippet.
• 👥 duplicates the top stack item.
• 🚜 Tractors have different attachments, to perform the same task (tilling, harvesting etc) on every row of the field. Similarly, 🚜 takes an attachment program and runs it on every item in a list.
• 🪄 Magically makes the top item disappear while executing the program beneath, then magically makes the item reappear.

Words in the dictionary that are made with emoji will have english documentation that you can search for, in case you forget which symbol it is. For example:

words [[1 doc] lookup "swap" contains?] 🧲 ▶️ 

[[🔀 [[definition builtin-function]
     [doc "The crossing arrows denote swapping the top two stack items."]
     [examples [[[1 2 3 🔀] [1 3 2] "Swap top two items"]]]
     [spec [[[item a]
             [item b]]
            [[item b]
             [item a]]]]]]]

So now we know 🔀 does the swapping.

You don't need to understand how that program above works yet, just know that you can run it yourself and replace "swap" with whatever word or phrase you want to search.

Often you have all the data a word needs on the stack, but it's in the wrong order. There's lots of handy words to help there.

🔀

swap the top two items

🛟

float the 3rd item up to the top

⚓

sink the top item down to 3rd

flip

reverse the top 3 items

These words can also be combined with dip and its variants to reach deeper into the stack.

When you're done with an item, you can 🗑️ it, which eliminates it from the top of the stack. If you know a word will consume an item you need afterward, you can 👥 it so you have an extra copy.

Kcats' stack-based nature can take a little getting used to, and the reversing of the order you wrote something can be a common stumbling block.

Notice how ⚖️ is designed to have the conditional/true/false branch in the order you expect when you write code. However remember if you print the stack, the order will be reversed - the false program will be on top, followed by the true program, followed by the conditional:

1 2 3 [🗑️ odd?] ["it's odd"] ["it's even"] ;; ⚖️

["it's even"] ["it's odd"] [🗑️ odd?] 3 2 1

This is a theme in kcats, where argument order is designed to make the code readable - if a word takes multiple arguments, and the order matters, the "first" logical argument is not the top of the stack. Here's an example:

1 2 <

✔️

When we write 1 2 <, we mean "1 is less than 2". Even though the top of the stack is 2, we don't consider 2 the "first" argument.

Sometimes you have a program that you don't trust with a certain stack item. Perhaps there's a password on the stack, and you're running an untrusted program given to you by someone else.

What if there was a way to hide that password behind your back such that the program never even knew it was there, and then restore it after the untrusted program was finished?

🪄 takes an item on the top of the stack, and a program. It temporarily makes the item disappear, and runs the program. After the program is done, the item reappears on top of the stack.

1 2 "mypassword" [+] 🪄

"mypassword" 3

Notice the addition program could not access the password even if it tried. It isn't on the stack while it's executing, it's hidden away elsewhere in the runtime, temporarily.

To demonstrate we can use the word 📸, which takes a snapshot of the entire stack and places it on top of the stack.

"foo" "bar" "hidden!" [📸] 🪄 

"hidden!" ["bar" "foo"] "bar" "foo"

So here we see the snapshot ["bar" "foo"], the word "hidden" nowhere to be found. That's because when the snapshot was taken, it was hidden away and wasn't anywhere on the stack. Then "hidden" is placed back on top after the snapshot is done.

🪄 is very common in kcats, and it's used mostly in cases where you don't actually care if a program reads an item, you just want the item out of the way temporarily, and it's easier than finicky swapping. However in cases where there is a trust issue, no amount of swapping can fix the problem and you definitely should reach for 🪄.

Kcats provides some facilities to let you avoid tedious cloning of items to keep from losing them. Most words consume items from the stack to produce new items. Sometimes you'll still need those old items again later.

Let's say you want to check if two items are equal, and if not, add them to a list.

Naively you might try this:

[] 5 6 [=] [] [[📮] 🪄 📮] ⚖️ ▶️

[[asked [consume]]
 [handled []]
 [reason "not enough items on stack"]
 [type error]
 [unwound [📮 [] 📮]]]

The problem is that = consumes both the numbers, just leaving a boolean. What if we could specify that the program [=] isn't allowed to permanently consume any stack items, it's just allowed produce a result?

That's what 🛡️ does.

5 6 [=] 🛡️ ▶️ 

[] 6 5

So we can just drop 🛡️ into the original program right after the program we want to modify, and that should fix things:

[] 5 6 [=] 🛡️ [] [[📮] 🪄 📮] ⚖️ ▶️

[5 6]

There are words like •🪄, •🛡️, •🔀, •🗑️, •🐋. What are those?

It's a modification of the original where the effect is one stack element further down from the original. Each dot represents a stack item that is above where the word has its effect (or where the word ends its effect). What exactly is further down, depends on the word.

•🔀

swap the two items beneath the top item (the 2nd and 3rd items).

•🪄

hide not the top stack item, but the top two items

•🛡️

instead of allowing no stack items to be consumed, allow one to be consumed.

•🗑️

drops the 2nd item instead of the top item

•🐋

hides the top two items but then floats the result back to the top above the previously hidden items

Similarly the deep variants are one level even deeper than that:

••🔀

swap the 3rd and 4th items

••🪄

hide the top 3 items

••🛡️

protect all but the top two items

••🗑️

drops the 3rd item

In kcats, when a program encounters an error, an error item is placed on the stack instead of the usual result.

2 3 "four" * + 

[[actual "four"]
 [asked [number?]]
 [handled 🔳]
 [reason "type mismatch"]
 [type error]
 [unwound [* +]]]
"four" 3 2

Notice the unwound field contains the rest of the program that remained when the error occurred.

We can fix the problem and continue, but only if we can stop the unwinding before our entire program is unwound. We can do that using the word 🩹, which creates a self-recovering program. It takes two component programs: p and r. p is run and if it results in an error, the unwinding is limited to p and then r is run. When r runs, the error item is on the top of stack. If there is no error, r does not run.

In the program below, we recover by discarding the error and the string "four", and replacing it with the number 4. Then trying the operations * + again.

2 3 "four" [* +] [🗑️ 🗑️ 4 * +] 🩹 ▶️ 

14

The problem with the usage of 🩹 above is that we had to specify the arithmetic words * + twice - once in p and again in r in case they failed the first time. Remember those operations are saved in the unwound field of the error, and we can access them and even ▶️ them. There is a word that does this for you: retry: it takes an error on the top of stack, and executes its unwound program.

2 3 "four" [* +] [[🗑️ 4] 🪄 retry] 🩹 ▶️

14

In the above program, after the error occurs, we discard the string underneath the error and replace it with the integer 4.

Sometimes you need to raise your own errors, you can do that with the word fail.

2
[odd?]
["ok"]
[[[type error] [asked odd?] [reason "expected odd number"]]
 association fail]
⚖️ ▶️
3 4 +

[[asked odd?]
 [handled 🔳]
 [reason "expected odd number"]
 [type error]
 [unwound [3 4 +]]]

Sometimes you want to handle some errors but not others. There's no error type matching like you'd find with java's catch. You have to recover, examine the error, and if it's one you don't want to handle, re-activate it with fail.

You're not stuck with just the vocabulary in the starting environment. You can add your own vocabulary!

https://rosettacode.org/wiki/Jensen%27s_Device

100 [0] [[1.0 swap /] dip +] primrec

5.187377517639621

36023425442111112

[] swap 2 ;;  current-divisor input result

[[sqrt] dip >=]
[[mod zero?] 
 [clone ;; c-d c-d i r
  sink ;; c-d i c-d r
  [put] dipdown ;; c-d i new-r
  / 2] ;; dividend new-r
 [inc] ;; c-d++ i r
 if]
while

drop put

[2 2 2 3 17 29 643781 4729211]

Prime factor generator

1231231231231231
2
[[[[[mod zero? not]
    [[sqrt] dip >=]] [execute] every?]  
  [inc] 
  while

  [mod zero?]
  [[/] shield dropdeep swap clone]
  [drop [] swap]
  if]
 bail]
collect dropdown

[89 3271 5683 744203]

[0 [1 2 3] [+] step] ;; the program to trace

[program] swap put wrap environment ;; create a starting env

;; now create a generator of environment states for each step of execution
[[[program] lookup] ;; if the program is not empty
 [eval-step clone] ;; step 
 [[]] ;; otherwise emit nothing to stop the consumption
 if]

;; consume the generator
collect

[[[stack [0]] [program [[1 2 3] [+] step]]]
 [[stack [[1 2 3] 0]] [program [[+] step]]]
 [[stack [[+] [1 2 3] 0]] [program [step]]]
 [[stack [[+] 1 0]] [program [execute [2 3] [+] step]]]
 [[stack [1 0]] [program [+ [2 3] [+] step]]]
 [[stack [1]] [program [[2 3] [+] step]]]
 [[stack [[2 3] 1]] [program [[+] step]]]
 [[stack [[+] [2 3] 1]] [program [step]]]
 [[stack [[+] 2 1]] [program [execute [3] [+] step]]]
 [[stack [2 1]] [program [+ [3] [+] step]]]
 [[stack [3]] [program [[3] [+] step]]]
 [[stack [[3] 3]] [program [[+] step]]]
 [[stack [[+] [3] 3]] [program [step]]]
 [[stack [[+] 3 3]] [program [execute [] [+] step]]]
 [[stack [3 3]] [program [+ [] [+] step]]]
 [[stack [6]] [program [[] [+] step]]]
 [[stack [[] 6]] [program [[+] step]]]
 [[stack [[+] [] 6]] [program [step]]]
 [[stack [6]] [program []]]]
[[[program] lookup] [eval-step clone] [[]] if] [[program []] [stack [6]]]

We could ensure the stack/program are printed in the same order each time

[0 [1 2 3] [+] step] ;; the program to debug

[program] swap put wrap environment ;; create a starting env

;; now create a generator of environment states for each step of execution
[[[program] lookup] [eval-step clone] [[]] if]

;; print with the fields sorted the same way for each step
[
 [[stack [[+] 3 3]] [program [execute [] [+] step]]]
 [[stack [3 3]] [program [+ [] [+] step]]]
 [[stack [6]] [program [[] [+] step]]]
 [[stack [[] 6]] [program [[+] step]]]
 [[stack [[+] [] 6]] [program [step]]]
 [[stack [6]] [program []]]]
[[[program] lookup] [eval-step clone] [[]] if] [[program []] [stack [6]]]

Instead of opening a github issue, add a TODO subheading to the Issues heading. Commit the change and submit it as a pull request. In the branch where that issue is being fixed, it will be changed to INPROGRESS. When the issue is fixed, the heading will be removed. (If you disagree that it's been fixed, submit a PR that reverts the commit to remove it).

You can edit this file right on github, in your own fork of the project, if you prefer.

Why do things this weird way? I don't want to rely on github, nice as it is.

Please do report design improvements you'd like to see - for example, inconsistencies in how words expect stack arguments to be, ways to make the standard library easier to work with, etc.

There's tooling planned that will help show what should be on the stack at any point in a given program. However until that exists, you can use comments to annotate your program line by line, and show what is on the stack at each step.

See 6.5 example.

This is admittedly low tech, but it isn't as tedious as you might first expect. You only have to pay attention to the stack items actually touched by the code you're writing, which usually is rather small - if you need to annotate a line with more than 5 or 6 items you are probably doing something wrong. The solution could be to use an association or list to hold multiple properties of the same conceptual object, in one stack item.

The logic rules are that empty containers are 'negative', and every other value is 'affirmative'. So the word no, by those rules would be affirmative, which would be very surprising! So the word no is not used in the language. To convey a logical negative, use empty list [].

The first thing to do is check the contents of the error. The unwound field will show you the instruction that failed along with the remaining program.

If that doesn't tell you enough about what's wrong (and it often doesn't), there are several more tools at your disposal:

• dump - this word prints the stack to stdout, if you add it to your program at strategic places, you can see if the stack looks the way you would expect at that point in the execution.
• built-in debugger - this allows you to step through program execution.
• tracing - see 6.10

This is due to a known unimplemented feature in the interpreter, or an unknown bug. Please see 9, and if you don't see it there, please add a new one and submit a pull request. Even for unimplemented features it's good to let us know you need that feature so we can prioritize it.

The goal is for kcats to never panic.

Users should not be required to know emacs to build the project, only have it installed. The build should be accessible from bash without having to use emacs interactively.

That was only there as a cheat when there was only the prototype implementation. The platforms are different and their function names don't belong in the lexicon.

I'm not even sure there should be platform interop at all - it doesn't appear to be possible in the rust impl anyway.

So far what I've done is have some lower level words actually in the dictionary but marked them like `++lookup`. I haven't decided what to do about this yet. Lower level words probably should just be first class citizens and I just need to think of better names. Right now the low level (single-depth) lookup is `++lookup` and the user-facing `lookup` does the arbitrary depth. In this case, the user-facing name probably needs to change to reflect what it does (something like `drill` or `extract`), and then the low level can just be `lookup`.

That means for all the i/o and crypto interactions, there needs to be low-level words. I'm not sure yet how to prevent namespace pollution, as one of the design choices is

Should change to match assign and lookup, accept a list instead of a single bare word.

Debuggers, spawning, ingesting etc

It would be nice to have a graphical display of all the environments in an application, and be able to

• Drill into the environment and read the stack/program/dictionary
• Pause/resume execution
• Apply debugging (breakpoint, step etc)
• View pipes and what/where they connect to (draw lines if they connect somewhere else in the app)
• Manually put things into pipes or take them out
• Create new envs
• Persist changes
• Revert changes

Let's say we write an app or library, how do we distribute it?

This ties in with durability - where do we store things in general, and not just libraries? kcats does support the filesystem but I would like that to be for compatibility only. The "native" kcats way of storing and retrieving things should be via hash keys. There may also be a fact database, probably with sparse tables (aka eavt format).

It brings up the question of what should "come with" the language. I am thinking maybe there's a "barebones" version of the language with no library management or anything. Then on top of that, build some durability and networking to distribute code and other data. Then the question is, what do we need to support in the base language? Seems like there needs to be database/network functionality there, but unused? Maybe make it a feature flag?

Let's explore the various options

I've been calling vec a lot, sometimes just so the list will print out with square braces. I now have a repr function that could do this, so using vec for that purpose is no longer needed.

However, I can't get rid of all of them- for example, calling conj on a vector vs list adds at different ends of the list so they are not interchangeable in that respect. It may be dangerous to leave any lists lying around if they might get conjed onto expecting it to go on the end.

10 0.5 *

5

"foo" encode

#b64 "Zm9v"

[[a b] [c [[d e]]]] [c d] 5 assign

[[c [[d 5]]] [a b]]

[[a b] [c []]] [c] [[d 5]] association assign

[[c [[d 5]]] [a b]]

[[a b] [c [[d e]]]] [1 1 0 1] 5 assign

[[a b] [c [[d 5]]]]

[[a b] [c [[d e]]]] [1 0] 5 assign

4 3 [>] shield [wrap [wrap] dip] dip sink branch 

4

yes 4 2 branch

[[asked [program]] [reason "type mismatch"] [type error] [unwound [branch]]] 2 4 yes

5
[1 2 "oh fudge"]
[[+]
 []
 recover]
map

[[[type error] [reason "word is not defined"] [asked [handle]] [unwound []]] [[unwound []] [asked [handle]] [reason "word is not defined"] [type error]] [[asked [number]] [type error] [reason "type mismatch"] [unwound [+]]]] 5

5 1 [+] [] recover

[[unwound []] [asked [handle]] [reason "word is not defined"] [type error]] 1 5

1 type

number

5.01 5 0.1 swap [- abs] dip <

yes

2000 clone 2 swap range ;; all the numbers up to n

[sqrt 2] dip  ;; start counter at 2, stop at sqrt of n
[sink =] ;; stop loop when the counter hits sqrt n
[[drop drop] dip]  ;; drop the original args, just leaving the primes
[[[[=] 
   [swap mod positive?]]
  [execute] any?] 
 filter ;; keep the counter but no multiples of it 
 [inc] dip] ;; increment counter
[execute]
recur

[[asked [consume]]
 [handled yes]
 [reason "not enough items on stack"]
 [type error]
 [unwound [sqrt 2 [[]] 🍫 [sink =]
           [[drop drop]
            dip]
           [[[[=] [swap mod positive?]]
             [execute] any?]
            filter [inc] dip]
           [execute] recur]]]

Here's a mimic of the python version, WIP:

;; num
10
[[[] [yes put]] dip times] shield ; a n
2 ;; p a n
[swapdown clone * > ] ;; while test
[[wrap lookup] ; if test - fetch by index
 [
 swapdown ;; p n a
 clone ; p
 clone * ; p^2 p n a
 ;; range wants p, n+1, p^2 
 sink ;; p n p^2
 [inc] dip ;; p n+1 p^2
 [range] shield ;; r p n+1 p^2 a
 [dec sink drop] dipdown ;; r p a n
 swapdown ;; r a p
 [ ;; i r a p
  wrap ;;swapdown ;; [i] a r p
  [[]] update ;; set to false: a r p
  swap ;; r a p
 ]
 step ;; a p
 swap 
 ] ; do the for loop
 [] ; else do nothing
 if
 inc ;; p++
]
while 

[[actual 2]
 [asked [sized]]
 [handled yes]
 [reason "type mismatch"]
 [type error]
 [unwound [update swap [8 10]
           [wrap [[]] update swap] step swap inc [swapdown clone * >] shield [[wrap lookup]
                                                                              [swapdown clone clone * sink [inc] dip [range] shield [dec sink drop] dipdown swapdown
                                                                               [wrap [[]] update swap] step swap]
                                                                              [] if inc [swapdown clone * >] shield]
           loop]]]
[[]] [6] 2 [yes yes yes yes [] yes yes yes yes yes]
10

[yes yes yes yes yes yes yes yes yes yes]

[] [[yes] 15 times] inject
2 swap ;; p a
[clone clone *] dip swap ;; p^2 a p
[[[📏] shield] dip swap [<] shielddown] ;; b p^2 a p  
[[wrap [drop []] update] shield ;; do the update 
 float drop sink [+] shielddown swapdown] ;; 
;while

[[wrap [drop []]
  update]
 shield float drop sink [+] shielddown swapdown]
[[[📏] shield]
 dip swap [<] shielddown]
4 [yes yes yes yes yes yes yes yes yes yes yes yes yes yes yes]
2

How do we write this code? Generally, how do we decide what order things go on the stack?

It looks like the array of bools is the main piece of data here, that is used throughout the algorithm. The other commonly used variable is p, the one that's incremented. I think probably p should remain on top. The outermost loop needs to know when to stop, and that needs to compare to num. That can go on the bottom.

The inner loop uses i. That should probably replace p on top when in use. So it should be [p a] and later [i a p].

Now that lingo exists, maybe should also write let for variables (where the values are evaluated before updating the dictionary)? Also these aren't actually "variables" because you can't change the value, without an inner let.

Actually this is probably best implemented in two parts:

• a word that takes a set of bindings and evaluates the values, leaving a map of word to value
• a word that takes the map above and inserts it into the dictionary. I think lingo does this already.

let's try to write the former here. I think we need map-values type of thing here, which requires treating a map as a list.

[[[a [+ 5 6]]
  [b [- 100 8]]]
 [a b +]
 let] 

ok round 2 here, let's just do the updating loop first: expect p, a, n, and modify a in place such that all multples of p are flipped to [].

10
clone yes swap repetition
2

first though let's just produce the array of indices to mark from p and n.

10 2
clone sink range

[2 4 6 8]

now given that and a, mark all those indices

1000 clone yes swap repetition 
2
swapdown
[clone * >]
[[dropdown wrap lookup]
 [[clone sink range rest] shield sink 
  [[wrap [] assign] step] dipdown]
 when
 inc]
while
drop drop
indexed
[second] filter [first] map
rest rest

[2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71
 73 79 83 89 97 101 103 107 109 113 127 131 137 139 149 151 157 163 167 173
 179 181 191 193 197 199 211 223 227 229 233 239 241 251 257 263 269 271 277 281
 283 293 307 311 313 317 331 337 347 349 353 359 367 373 379 383 389 397 401 409
 419 421 431 433 439 443 449 457 461 463 467 479 487 491 499 503 509 521 523 541
 547 557 563 569 571 577 587 593 599 601 607 613 617 619 631 641 643 647 653 659
 661 673 677 683 691 701 709 719 727 733 739 743 751 757 761 769 773 787 797 809
 811 821 823 827 829 839 853 857 859 863 877 881 883 887 907 911 919 929 937 941
 947 953 967 971 977 983 991 997]

Now take an array of bools and filter by index

[yes [] yes] [📏] shield [0] dip 1 range swap zip
[second] filter [first] map

[0 2]

this is too inefficient (copying the whole array due to the shield

[
wrap [] assign] shield

Need to avoid using shield, as it causes copying of the large array.

[1 2 3] [0] 100 [pair] shield [assign] dip 🍫

100 [0] [100 2 3]

Kcats is difficult to use in the same mindset as other languages. The amount of complexity you can fit into a single function or subroutine, before it gets too difficult to reason about, is quite a bit smaller. However kcats is designed to be used this way. The kcats way is building small combinators, and then using those combinators to build what you need.

Kcats has some distinct advantages here:

• The overhead of putting pieces together is basically zero, since function composition is the default.
• Combinators are very easy to test independently.

Kcats makes it easy to test combinators independent of the context where you will use it. In purely functional code, this is straightforward: you just place some sample data on the stack and then the combinator you want to test, then run it.

With i/o it's not quite as straightforward. However kcats pipes are designed to be easily swappable for regular values. Let's say you have some code that expects to read from a file but you want to test it without having to maintain state in your local filesystem:

"bar" file-out
take string

"Hello World!" [[type tunnel]
                [values [[type bytes]]]
                [to [[file "bar"]]]]

Swap the file-out pipe for a plain list of byte arrays, they have the same interface, and gives the same result:

[#b64 "SGVsbG8gV29ybGQh"]
take string

"Hello World!" []

and of course you can build that byte array out of strings, if you prefer:

["Hello World!"] [encode] map
take string

"Hello World!" []

This technique works for any use case where you're using a pipe for its usual take/put/step interface, and timing is not critical.

I wonder whether kcats should have any notion of files and sockets at all. Sort of like java doesn't have any notion of memory addresses or malloc/free - it operates at a higher level and handles mem management for you. Maybe kcats handles persistence for you. This may be a sort of chicken/egg problem where I need a network protocol to help w persistence and I want that protocol to include kcats as a language. Can they be bootstrapped as a single unit? Seems possible but not easy. Persistence might involve having another party store data for you, which might involve identity (to limit access) and money (to incentivize someone to keep your data for later). That might be a bit of a reach for a programming standard lib to handle.

And then there's the question of interop with other programs, how would they communicate if kcats doesn't know what a file or socket is? Maybe it can know what a file/socket is but you don't need to use it except as interop (like clojure's java interop or java's jni).

So what would this look like?

Instead of telling the program where to persist, you just want it persisted and you get a sort of claim check (maybe the hash of the data?). Then to get it back later, you present the claim check. Persistence is a best-effort deal (you can't be 100% sure no disaster could wipe it out). So maybe also include some optional params to indicate:

• how long until you might need this again
• how long you can wait between requesting it and getting it
• how disaster-proof it needs to be
• how much you're willing to pay to store it

Maybe we can even put messaging under this model - after all, sending someone a message is in fact making a copy of data you have. You don't necessarily want to retrieve it later though.

Computing might be better thought of as a worldwide resource - you might not be able to trust someone else to do a computation for you (yet, unless it's a specific type where you can verify without doing the full computation yourself) but you can trust them with storage (given enough redundancy - they can't steal your data because it's encrypted).

Often we create objects similar to java construction, where the input and output are informationally equivalent (you can reconstruct the output from the input anytime you want, and sometimes vice versa).

It might be nice if kcats didn't force you as a user to do this type of operation and just let you use the original data.

For example, lets say you have [[file "/tmp/foo"]]. That's an association of file (a type) to a string. Really what that means is we're referring to a file on disk. In java we'd construct a File object with new File("/tmp/foo"). It'd be nice if everywhere in kcats you never needed a File object and could use the original descriptor instead (or a pipe you've already created, if state matters). On the jvm platform obviously somewhere a File object would get created but that should be hidden from view. How would that work?

I thought of a word like derive that caches these things? Maybe it would keep a cache of previously derived things and just return the answer if asked again (like memoized function in clojure and could even be implemented that way). It would also have a mapping of how to derive one thing from another. eg [[file "foo"]] and create a pipe-in to write to it. You'd first need an inputstream to the file (as inputstream is what the pipe protocol is actually using).

The thing is, inputstreams are not values. They're stateful, pointers to places on disk. So we probably can't cache them nor need to.

derive would be more for things like crypto keys created from a seed.

For pipes, we need to go from a descriptor, to some platform specific object, to a pipe. How do we keep platform specific code isolated? I'm hesitant to make public abstractions for anything but pipes. I don't want a file word that creates file objects from descriptors, kcats users should never see that. The only solution I can think of is to just leave the platform-specific code where it is, and have some kind of switching mechanism like clj/cljs has.