Link to ktye's K compiler

1 files changed, 1 insertions, 1 deletions

diff --git a/implementation/kclaims.md b/implementation/kclaims.md
index 98c22803..5aa085ad 100644
--- a/implementation/kclaims.md
+++ b/implementation/kclaims.md
@@ -36,7 +36,7 @@ K's design is well-suited to interpreting scalar code because of its simplicity.
 
 But K still isn't good at scalar code! It's an interpreter (if a good one) for a dynamically-typed language, and will be slower than compiled languages like C and Go, or JIT-compiled ones like Javascript and Java. A compiler generates code to do what you want, while an interpreter (including a bytecode VM) is code that reads data (the program) to do what you want. Once the code is compiled, the interpreter has an extra step and *has* to be slower.
 
-This is why BQN uses compiler-based strategies to speed up execution, first compiling to [object code](vm.md#bytecode) and then usually further processing it (compilation is fast enough that it's perfectly fine to compile code every time it's run). In particular, CBQN can compile to x86 to get rid of dispatching overhead. K and Q are always described by developers as interpreters, not compilers, and if they do anything like this then they have kept very quiet about it.
+This is why BQN uses compiler-based strategies to speed up execution, first compiling to [object code](vm.md#bytecode) and then usually further processing it (compilation is fast enough that it's perfectly fine to compile code every time it's run). In particular, CBQN can compile to x86 to get rid of dispatching overhead. And ktye's somewhat obscure K implementation now has [an ahead-of-time compiler](https://github.com/ktye/i/tree/master/kom) targetting C, which is great news. Commercial K and Q are always described by developers as interpreters, not compilers, and if they do anything like this then they have kept very quiet about it.
 
 ## Parallel execution