cpyte 4.6.5

NOTICE: It seems cpyte has been going through a lot of changes, including the OOP work which was quite fabulous and python-like. I liked how the syntax changes very interestingly and made the language better. However, after a lot of experimentation and many breaking changes, I've decided that the syntax lock is now settled. The language is being stabilized, and development will slow down as we focus on reliability and polish instead of constant churn. After that, improvements will be delivered through the @std/improvements package with the extension hook framework.

Check out the official documentation here.

Package Extensions

Cpyte supports a package extension system that allows packages to extend the compiler with custom keywords, operators, and compiler hooks. Packages can provide:

• Custom Keywords: Add new language keywords via package.json
• Custom Operators: Define new operators for syntax extensions
• Compiler Hooks: Extend lexing, parsing, semantic analysis, and code generation
• Runtime Extensions: Add runtime code and libraries

Package Structure

Packages are stored in .cpm/modules/package_name/version/ and can include:

• package.json - Extension manifest declaring capabilities
• parser_hooks.py - Custom syntax extensions
• semantic_hooks.py - Custom type checking and analysis rules
• codegen_hooks.py - Custom LLVM IR generation
• runtime_hooks.py - Runtime code and libraries
• *.cpy - Main package entry point
• *.ll - Prebuilt LLVM IR

Example Package

See examples/example_package/ for a complete example package with:

• Custom keywords: async, await, defer
• Custom operator: ~~
• Parser, semantic, codegen, and runtime hooks

Using Extension Packages

import @package_name

# Use custom keywords and syntax from the package
async def my_function() -> Promise:
    # Custom syntax
    defer cleanup()
    return result

Examples

You'll find comprehensive examples in the examples/ directory that cover C imports, header imports, 64-bit support, and standard library usage:

You can also import .cpy files — the examples show how to use import "other.cpy" to bring in public functions and structs from other Cpy files.

Run any example with:

cpy examples/<filename>.cpy

Note

Cpyte is experimental software. The compiler is continuously tested with fuzzing and a regression corpus, and every release is published to PyPI and Gitea.

Memory Management

Cpyte uses a concurrent tri-color garbage collector for automatic memory management. Heap-allocated objects (via new) are managed automatically — no manual free needed.

Note: The collector adds a small runtime overhead (~5-10%) compared to manual malloc/free. For performance-critical ecosystem projects or embedded use cases, this trade-off may be significant. The GC is required for safety but will slow down programs that do heavy heap allocation.

Cross-Platform Runtime

The compiler is fully cross-platform. On every target OS (macOS, Linux, Windows) the C runtime (runtime.c), the GC runtime (gc_runtime.c), and any embedded ccode: blocks are compiled from source at JIT/AOT time for the host platform, rather than linking pre-built, OS-specific bitcode. This keeps native helpers and the garbage collector correct on each system:

• Portable threading: pthread on POSIX; native Windows threads + CRITICAL_SECTION on Windows.
• Portable stack scanning for the GC that works on macOS, Linux, and Windows.
• A portable sleep/yield helper replaces the POSIX-only nanosleep.

The compiler auto-discovers a C compiler (clang → cc → gcc) and system linker on the current platform, so cpy, cpy build, and cpy --aot all work without per-OS configuration.

Continuous Integration

GitHub Actions (see .github/workflows/code_quality.yml) builds and runs a curated, cross-platform regression corpus on Ubuntu (x86_64 + arm64), macOS (x86_64 + arm64), and Windows. ci_test.py AOT-compiles each program with the system linker and executes the result to exercise the full pipeline — lexer, parser, semantic analysis, LLVM codegen, the C and GC runtimes, and linking.

CI Benchmark Results

The table below is updated by the benchmark CI job on main. It is a separate measurement from any historical benchmark results and is collected on the dedicated benchmark runner.

Benchmark results will appear here after the next successful benchmark CI run.