F Memory Management

Prev | Home | Next

Appendix F: Memory Management (Future)

The language specification currently does not include heap memory management. This appendix documents potential future approaches.

Current State: All values are stack-allocated or embedded in data structures.

Pointer Types: The ptr type for raw pointers is planned as a future feature and will be part of the memory management system.

Potential Approaches:

Option A: Manual Management

// Allocate on heap
3.0 4.0 Point alloc     // ( Point -- ptr<Point> )

// Dereference
ptr deref               // ( ptr<T> -- T )

// Store through pointer
new_value ptr store     // ( T ptr<T> -- )

// Free memory
ptr free                // ( ptr<T> -- )

Pros: Full control, predictable, zero overhead
Cons: Error-prone, requires discipline, potential memory leaks

Option B: Reference Counting

// Create reference-counted value
3.0 4.0 Point rc        // ( Point -- rc<Point> )

// Automatic reference counting
value dup               // Increments count
drop                    // Decrements count, frees if zero

Pros: Automatic cleanup, relatively simple
Cons: Runtime overhead, cannot handle cycles, larger memory footprint

Option C: Ownership System (Rust-like)

// Linear types - each value has one owner
value                   // Move semantics by default
value dup               // Error: cannot copy owned value
value ::clone call      // Explicit clone required

Pros: Memory safe, zero overhead, prevents leaks
Cons: Complex type system, restricts stack operations, steep learning curve

Option D: Arena/Region-Based

// Create arena
::arena new             // ( -- arena )

// Allocate in arena
arena 3.0 4.0 Point alloc_in  // ( arena Point -- ptr<Point> )

// Free entire arena
arena free_arena        // ( arena -- )

Pros: Fast allocation, simple bulk deallocation
Cons: Less granular control, memory held until arena freed

Recommendation: Start without heap allocation (current approach). When needed, implement Option A (manual) for simplicity, with Option D (arenas) added later for performance-critical code. The stack-based nature makes ownership tracking (Option C) particularly challenging.

Type Parameter Enforcement Enhancement:

Current State: Type parameters in generic functions are currently suggestions and are not enforced at parse time.

Example:

(T -- T) { dup * } ::square fn  // Currently no error even without Multiplyable constraint

Future Enhancement: The compiler could enforce that type parameters actually constrain how operators and functions act, validated at parse time:

(Multiplyable -- Multiplyable) { dup * } ::square fn  // Enforced constraint

This would provide stronger type safety but add complexity to the type checker.

Testing Framework (Future):

Current State: Basic assert operator is available for inline testing.

Future Design: A comprehensive testing framework with dedicated operators.

Proposed Operators:

// Define a test
{ { 2 3 + } { 5 == } assert } "addition test" test

// Test for expected errors
{ 1 0 / } "division by zero test" test_error

// Test suites
{ 
    { 2 3 + 5 == } "addition" test
    { 5 2 - 3 == } "subtraction" test
} "arithmetic tests" test_suite

Features:

Documentation Comments (Future):

Proposed Syntax:

/// Calculates the square of a number.
/// Takes a number and returns its square.
(Number -- Number) { dup * } ::square fn

/// A point in 2D space.
/// Fields:
///   x: The x-coordinate
///   y: The y-coordinate
(T T --) { x: y: } ::Point<T> struct

Features:

Advanced Compiler Directives (Future):

Beyond the basic shebang, future versions may support:

#require "0.9.0"          // Minimum language version
#optimize speed            // Optimization hints
#allow unsafe              // Enable unsafe operations
#deprecated "Use new_fn"   // Deprecation warnings