Chirp is being built as a systems programming language. Two things make its design unusual:

• Chirp code is a script that defines the program to be compiled, using the same machinery for metaprogramming as the code being built.
• It uses a powerful and extensible set-theoretic constraint system in which guarantees are garden-variety values.

These two things play off of each other to create an unusually expressive and (I think) harmonious way to define compiled programs using surprisingly few building blocks.

For the whole story behind the what/why, have a look at motivation.md.

Getting started

Requirements: CMake 3.20+, a C++20 compiler and a network connection for FetchContent() to be able to do its thing for googletest.

cmake -B build
cmake --build build && ctest --test-dir build

build/interpreter/chirp script.chirp

Here's a sample script you can try:

let fizz = { x:int | x % 3 == 0 };
let buzz = { x:int | x % 5 == 0 };

for (v ∈ 1..100) do {
    let out = match v {
        fizz ∩ buzz => "fizzbuzz",
        fizz => "fizz",
        buzz => "buzz",
        `any => v
    };

    `print(out);
};

Misleading intuition warning

If you are a seasoned developer and, as I suspect will likely be the case, you go have a look at some code samples before reading the spec, you will find yourself in almost familiar territory, and there's a real risk of misinterpreting what's going on.

                This
                 |
                 v
let some_var : int64 = 3;

Is NOT the variable's type in Chirp. Thinking about it this way is not the end of the world and won't prevent you from using the language, but it shackles you in a way where you'd miss out on a lot of what the language has to offer. The full explanation is in the motivation.md file.

After that, the user guide will cover the basics.

State of the project

How stable is Chirp?

• The syntax and grammar are quite stable at this point. They aren't formally locked down yet though.
• The semantics are "mostly" stable, but there's a few points that are still a bit shaky
  • Set enumerability, finiteness and coextensiveness are likely to undergo tweaking.
  • Call signature checks are still a bit too loose for my liking.
  • Supersets and subsets are intentionally not dealt with right now, but we need to reckon with them eventually.
  • Function purity is not enforced quite as hard as it should be yet.
  • Mixed-typed binary operators are currently not supported, but will be.
• The standard library is not to be trusted at all for the time being.

Current objectives

• Develop an IR-based interpreter, so that the static solver has something to manipulate.
• Start populating the standard library.

Roadmap

Chirp is interpreter-first, but not interpreter-only. It's ultimately meant to be a metaprogramming systems-level tool. But at the same time, the dynamic interpreter meta-language makes a suitable scripting tool in its own right, as a sort of "dynamically enforced TypeScript".

Because of this, the roadmap is split up in two:

Part 1: Dynamic Chirp

MILESTONE: Start publishing Dynamic Chirp v0.1 (DONE!)

1. Populate the standard library
2. Implement the IR-based interpreter

MILESTONE: Evaluate the road to a Dynamic Chirp v1.0

Part 2: Static Chirp

1. Implement the static solver, the target should be TypeScript-ish level of provability
2. Implement the Calcification process to narrow bindings down to representable types.
3. Implement low-level code emission

MILESTONE: Start publishing Static Chirp v0.1

How far we can take it from there is unclear. I am reasonably confident that it will work for straightforward single-threaded computations (which is already something!). But where will the framework hit a hard wall? I have no idea at the moment.

Repo map:

examples/ : A collection of non-trivial examples of chirp code.

interpreter/ : A work-in-progress C++ interpreter. It can run Chirp scripts, load boot sources, dump ASTs, and do in-place ASCII->unicode operator replacement.

lib/chirp/boot : Chirp tries to define itself via its own language as much as possible. This is the Chirp-specified bridge between the raw interpreter and user code.

lib/chirp/std : This is where the standard library lives.

docs/spec/ : It's not trying to be a legalese-style spec at the moment. Formalism will happen once the dust settles a bit.

scripts/ : Developer utilities, including the conformance test runner.

tests/ : A chirp-based test/conformance suite. Run via scripts/test_conformance.py.

Contributing

If you are looking at contributing to chirp itself, here's a few things to know.

Running the test suite

The tests/ directory contains a bunch of chirp-written tests.

It's hooked up to run automatically when invoking ctest. But you can also run it manually, passing it the chirp executable as a parameter.

python scripts/test_conformance.py -j auto path/to/chirp

Areas of (dis) interest

I wouldn't bother trying too hard to improve the current interpreter. It's the most naive of implementations to make the language work enough to poke it with a stick. A better designed one is already in the works.