Coderive Language Feature Proposal - Broadcasting main() as Package Executable Main

Published: (December 27, 2025 at 06:33 AM EST)
4 min read
Source: Dev.to

Source: Dev.to

Cover image for Coderive Language Feature Proposal - Broadcasting main() as Package Executable Main

Danison Nuñez

Core Concept

One broadcasted main() per package that any file in the package can execute.

Rule 1 – Broadcast Declaration

Only one file per package can declare a broadcast.

// File: app.cod (the broadcaster)
unit my.app (main: BusinessLogic)  // ✅ Only one per package

BusinessLogic {
    share main() {
        outln("Running business logic...")
    }
}

Rule 2 – Execution Priority

When executing any .cod file the interpreter follows this order:

  1. File’s own main() (if it exists) → runs immediately.
  2. Package broadcast main() (if declared) → loads and runs it.
  3. Error → no entry point found.

Rule 3 – Broadcasted main() Is Execution‑Only

Broadcasted main() methods cannot be called from code.

  • ❌ Not from other files
  • ❌ Not from the same file
  • ❌ Not from the same class
  • ✅ Only executable by the interpreter as an entry point

Rule 4 – Any File Can Trigger Execution

Any file in the package can execute the broadcasted main().

Complete Examples

Example 1 – Standard Package

File Structure

myapp/
├── logic.cod   # Broadcasts main()
├── dev.cod    # Executes broadcast
├── test.cod   # Executes broadcast (has its own main)
└── prod.cod   # Executes broadcast

Code

// File: logic.cod (broadcaster)
unit my.app (main: AppLogic)

AppLogic {
    share main() {
        outln("App running...")
        // Business logic here
    }
}

// File: dev.cod (executor)
unit my.app
// No main() → will execute AppLogic.main()

// File: test.cod (executor with local main)
unit my.app

TestRunner {
    share main() {  // Local main wins (Priority 1)
        outln("Running tests...")
    }
}

// File: prod.cod (executor)
unit my.app
// No main() → will execute AppLogic.main()

Execution Results

$ cod dev.cod
> App running...           (Runs broadcast)

$ cod test.cod
> Running tests...         (Runs local main, overrides broadcast)

$ cod prod.cod
> App running...           (Runs broadcast)

Example 2 – Library with Demo

File Structure

mathlib/
├── library.cod   # Main library logic
├── demo.cod      # Example usage
└── benchmark.cod # Performance test

Code

// File: library.cod
unit math.lib (main: MathLibrary)

MathLibrary {
    // ❌ Cannot be called (broadcasted)
    share main() {
        outln("Math Library v1.0")
        showExamples()
    }

    // ✅ Can be called
    share add(a: int, b: int) -> int {
        return a + b
    }

    // ✅ Can be called
    share showExamples() {
        outln("2 + 3 = " + add(2, 3))
    }
}

// File: demo.cod
unit math.lib

Demo {
    // Local main overrides broadcast
    share main() {
        math := MathLibrary()
        outln("Demo: " + math.add(5, 7))
    }
}

// File: benchmark.cod
unit math.lib
// No main() → executes MathLibrary.main()

Execution

$ cod library.cod
> Math Library v1.0
> 2 + 3 = 5

$ cod demo.cod
> Demo: 12                 (Local main runs)

$ cod benchmark.cod
> Math Library v1.0        (Runs broadcast)
> 2 + 3 = 5

Example 3 – Web Application

File Structure

webserver/
├── server.cod   # Main server logic
├── dev.cod      # Development mode
├── prod.cod     # Production mode
└── health.cod   # Health check (special)

Code

// File: server.cod
unit web.app (main: WebServer)

WebServer {
    // Execution‑only entry point
    share main() {
        loadConfig()
        setupRoutes()
        startServer()  // Blocks forever
    }

    // Callable methods
    share loadConfig() { ... }
    share setupRoutes() { ... }
    share healthCheck() -> bool { ... }
}

// File: dev.cod
unit web.app
// Could set: DEBUG=true, PORT=3000
// Then runs WebServer.main()

// File: prod.cod
unit web.app
// Could set: PORT=80, WORKERS=4
// Then runs WebServer.main()

// File: health.cod
unit web.app

HealthMonitor {
    // Special case: doesn't start server, just checks
    share main() {
        server := WebServer()
        healthy := server.healthCheck()  // ✅ Can call this
        outln("Healthy: " + healthy)
    }
}

Execution

$ cod dev.cod
> [Starts server in dev mode]

$ cod prod.cod
> [Starts server in production mode]

$ cod health.cod
> Healthy: true           (Runs local HealthMonitor.main())

Example 4 – Error Cases

Multiple Broadcasts (Error)

// File A:
unit my.pkg (main: App1)  // ❌ ERROR: Already declared in File B

// File B:
unit my.pkg (main: App2)  // First one wins? Error?

Calling Broadcasted main() (Error)

// File: caller.cod
unit my.app

Caller {
    share test() {
        AppLogic.main()  // ❌ ERROR: Cannot call broadcasted main()
    }
}

No Entry Point (Error)

// File: empty.cod
unit my.app
// No local main, no package broadcast
$ cod empty.cod
Error: No executable main() found

Package 'my.app' has no broadcast entry point.
Add to any file: unit my.app (main: ClassName)

Rule Summary Table

ScenarioWhat HappensExample
File has main()Runs local maintest.cod runs tests
File has no main(), package has broadcastRuns broadcasted maindev.cod runs AppLogic.main()
File has no main(), no broadcastErrorempty.cod fails
Trying to call broadcasted main()ErrorCaller.test() fails
Multiple broadcasts in packageFirst wins? Error? – design decision needed

Key Benefits

  • Consistency – One way to run the package
  • Flexibility – Files can override with a local main()
  • Separation – Logic vs. execution points
  • Tooling – Different files for different purposes
  • Clarity – Explicit broadcast declaration

Philosophy

“One canonical way to run the package, accessible from anywhere in the package, overrideable when needed.”

This approach is clean, practical, and elegantly simple!

Back to Blog

Related posts

Read more »

New scripting language

Overview I'm currently working on a scripting language that aims to “make developers' lives a little sweeter”. It's called Amai, runs on a bytecode VM, and is...