Memory Safe Programming Language

Copyright 2026 McPherran
License

---

Language Design/Concepts

Language Features

• Function and pipeline oriented, top-down for readability
• Traditional OO-classes unused (represented by operational pipeline)
• Automated imports (no #include/import syntax)
• Namespaces are based on directories
• Memory Safety
• Syntax Fosters AI/Scanning
• High Performance
• Power Efficiency
• AMD64 ABI (C-ABI) Support

Details

Data Management

• Mutability syntax
• No properties (unneeded)

Operational (Functional) Pipeline

• All functions are unary or binary (operation-like)
• The arg(s) to an operation may be a data set
• Operations are named functions and symbolic operators, e.g. +, -, *, ...
• Pattern matching
• Imperative statements supported (TBD)
• No return statements
• Pattern match or value as last statement is return value
• Function call acts as data/value
• Value of function uses struct member access syntax
• Boolean status optionally associated with function
• Parentheses unused for functions without an arg

General Minimization of Declaration of Variables

• Function call syntax provides effective return value variable
• Return value is either primitive or struct
• Explicit declaration of variables is generally unnecessary
• Automatic sequence variables (loop, span, list, hash, array, ...)
• Types not implied, clear from context.

Code Organization

• Translation units based on hierarchies (e.g. namespaces, types)
• Directories define namespaces (under project root)

No Exceptions (clean, performant)

• E.g. no throw/catch
• See Functions (boolean status)

Memory Safety

• Memory Management: Entry/Exit Design

  • Software operations are partitioned as Memory IO boxes.
  • A Memory IO box has an Entry/Exit stage (analogous to In/Out)
  • Memory is Acquired at the box Entry and Released at the box Exit
  • Memory Acquisition/Release occurs only at box Entry/Exit
  • Mode: Acquisition/Release may be alloc/free or pool get/return
  • Attributes control mode and pool sizes
  • Memory management is part of the application design
  • No garbage collection (GC)
  • Boxes can contain smaller boxes with the same paradigm
  • Async operations supported, box memory generally thread-local
  • Fast compilation, high-performance runtime, deterministic

• Normal Context

  • No global variables (local and module-level only)
  • No pointers
  • No allocations
  • No garbage collection
  • Memory managed as part of language
  • Unsafe contexts allowed

• Unsafe Context

  • No pointers
  • Addresses and ranges (arrays, bounds)
  • Memory-mapped structs (e.g. for drivers)

• Why No Garbage Collection (GC)

  • Manage memory safety once at compile-time, not repeatedly at run-time
  • GC indulges haphazard coding; Reduces AI-compatibility
  • GC negatively impacts performance and determinism
  • GC unnecessary (e.g. Rust)
  • GC works for memory safety, but it's deprecated

• See Also:

  • CISA - Memory Safety
  • F# native compiler initiative

Reduce Unproductive Decision-Making (Code Clarity, AI)

• No referring to "operator precedence"
• Parentheses required when needed, disallowed when not
• Syntax provides clarity when parentheses disallowed/unnecessary
• Prevent confusing math equations and boolean logic
• Functional approach to math/logic/operators
• FP/OO (foo) approach fosters data pattern recognition

Reduce Unproductive Debates

• Syntax minimizes need for conventions
• No "when are parens needed/better" debates
• Indentation uses tabs. Tab size of 2 spaces recommended.
• Builder enforces tabs of size 2 or 4.
• Most syntax lowercase only
• Line comments only, no comments on same line as code
• Self-documenting code is standard/convention