cpyte 4.6.1

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, as many changes are breaking-change and usualy a prone to error, I've decided to finalize a syntax-lock, in just a 2 months. 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.