Kip: a programming language where Turkish case endings are types

Case endings as the type of an argument

The idea is stated in one sentence in the readme, and it is unusual enough that the sentence is worth reading carefully. Kip uses Turkish noun cases to determine argument relationships in function calls, and the whole point is that the case suffix on a word is the type. The table lists the cases with their Turkish names, their suffixes and an example, and the list is the specification of the type system. Nominative has no suffix, as in defter. Accusative is the i hali with the suffix spelled in four ways depending on vowel harmony, giving sayıyı. Dative is the e hali with -e and -a, giving sayıya. Locative is the de hali with four suffixes, giving listede. Ablative is the den hali, also four suffixes, giving listeden. Genitive is the Tamlayan eki, giving sayının. Instrumental is the le eki, giving sayıyla. And there is a third-person possessive form, the Tamlanan eki, giving ardılı. That last one is the interesting case in the list, because a possessive suffix is a relationship rather than a role, and folding it into the same mechanism as the grammatical cases is the design decision that makes the project a genuine experiment rather than a keyword rename.

Argument order stops mattering, and that is the point

The consequence of typing arguments by case is that the order of arguments becomes free, and the documentation gives the demonstration directly. These two calls are equivalent:

(5'le 3'ün farkını) yaz.
(3'ün 5'le farkını) yaz.

The condition attached to that is the part to hold on to, because it is where the type system does its work. As long as arguments have different case suffixes or different types, Kip can determine which argument is which. So the flexibility is not unlimited, it is exactly as wide as the distinguishability of the arguments allows, and two arguments carrying the same suffix in the same position are ambiguous. That is a real constraint on how you write a function, and it is a constraint that arrives from the language rather than from a convention. For a programmer used to positional arguments, this is the single biggest adjustment, and for a linguist it is the point of the whole exercise, since Turkish argument order really is determined by the case rather than by position.

Data types, pattern matching and constants

The rest of the language follows the same idea of putting a grammatical construction where a programmer would expect a syntactic one. Inductive data types are defined with Turkish syntax, so a truth value is written as a sentence saying it may be true or may be false, and a traffic light type says it may be red or yellow or green. Polymorphic types work the same way, with a list type defined as either empty or an element added to a list. Pattern matching uses the conditional suffix, so a function matches on whether a value is true and returns the opposite otherwise, and the documentation notes that nested pattern matching, binders and wildcard patterns are supported, with the wildcard written using a negation suffix. The traffic light example is the one to read, because it shows the pattern syntax at its most readable, with a branch for red that stops, a branch for yellow that prepares and a branch for green that passes. Constants are defined with a definition sentence, so a greeting constant and a world constant are each a name followed by the suffix that marks it as a definition of a string.

The built-in types are small and named in Turkish

The standard library is deliberately minimal, and every operation is a Turkish word, which makes the naming an exercise in translation as much as in programming. Integers, called tam-sayı, offer arithmetic with toplamı, farkı and çarpımı, comparison with eşitliği, küçüklüğü and büyüklüğü, and a factorial operation given as faktöriyeli. Strings, called dizge, have uzunluğu for length, birleşimi for concatenation and tam-sayı-hali for parsing into an integer. Input and output are yazmak and okumak, with the shorter forms yaz and oku. Effects and sequencing are handled with the suffixes -ip, -ıp, -up and -üp, and binding uses the word for, so the greeting example reads as a definition of a greeting function that reads a name and writes a concatenation. Comments use a two-character delimiter in the same style as a Lisp block comment, and the literal syntax is the interesting one, because a literal carries its case suffix, so an integer literal, a string literal and a floating point literal each have a suffix attached to the value.

Building it needs a morphology toolkit and a Haskell toolchain

The build requirements are unusual and tell you what the implementation is doing. The first prerequisite is Foma, a finite-state morphology toolkit, with install commands given per distribution, and the second is Stack 3.11.1 or newer, the Haskell build tool with GHC 9.14 support. The build itself is either the install script or a manual pair of commands:

# Quick install (macOS/Linux)
chmod +x install.sh
./install.sh

# Or manual build
stack build

# Install to PATH
stack install

That Foma is a build dependency tells you the analyser is not a lookup table but a finite-state transducer, and the repository bundles the Turkish morphology transducer as a file under the vendor directory. The project is written in Haskell, with a Cabal package file, a stack configuration and its lock file, and the source is split into a directory of Haskell modules, a directory of native code, a library directory, an application directory, a playground directory, a tests directory and the vendor directory. The tip in the readme is worth noting too, that if you only want to explore the language you can start the interpreter after a successful build.

The command line covers the REPL, codegen and diagnostics

The runtime commands show that this is a compiler as well as an interpreter. The bare command starts the REPL, and there is a flag to execute a file, a flag to run in test mode which is non-REPL with definition logs enabled, and a flag to build or update the .iz caches for a file or a directory tree. The two codegen modes are the most interesting, since one generates JavaScript and the other generates strict ES modules into a directory, with a documented output layout of a runtime module for the runtime and primitive exports, one module per input or dependency .kip module, and an entry module that imports the requested inputs. There is also a flag to choose the diagnostic language, with a Turkish and an English option, and a flag to disable the automatic loading of the prelude library. A separate playground runner binary exists for the non-interactive case, and the readme explains a failure mode that will otherwise confuse you, which is that if the binary cannot find the transducer or the prelude file it is usually being run outside the installation layout Cabal expects, and it documents the search order and the environment variable that overrides it.

A language server, two editor plugins and a stated experimental status

The tooling is real rather than aspirational. The language server speaks the protocol over standard input and output, so it can be driven directly from an editor, and the repository ships a Visual Studio Code extension and a Vim and Neovim plugin, both of which use that server. The extension is built from source with npm and then run with the extension development path flag pointed at the plugin directory, and the readme is careful about the path requirement, that the server must be on the PATH or given as an absolute path. The project also publishes a citation file, which is a sign that it is meant to be referenced in academic work. The status statement is the thing to read before investing time, and it appears three times. The project is described as a research and educational project exploring the intersection of linguistics and type theory rather than a production programming language, the note says Kip is experimental and to expect changes in syntax and behaviour over time, and the language changes with every release, which is what a language in flux looks like. The name itself means grammatical mood in Turkish, and the readme also points to tutorials in Turkish and in English for learning to write programs in it.

Editorial conclusion

Kip is a good fit for a reader who wants to see what it would mean to put natural language morphology inside a type system, and for a linguist who wants to check whether the case analysis in the language matches their own, since the table of suffixes is explicit and the implementation is readable. It is the wrong tool for shipping anything, because the documentation itself describes it as a research and educational project rather than a production language and warns to expect changes in syntax and behaviour. It is also the wrong tool if you want to learn Turkish, since the language is about morphology as a typing discipline and not about teaching the grammar. Before building it, install Foma, the finite-state morphology toolkit the project depends on, because the analyser is not a dependency you can skip, and expect the Turkish morphological transducer to be needed at runtime as well as at build time. The project is MIT licensed, the last push was on 2026-09-26, and it publishes no GitHub releases.

Frequently asked questions

Official sources

1. Issues
2. kip-dili/kip on GitHub
3. License: MIT
4. Project website
5. README