vict00r99/rune-stone/rune-multi-lang

How to Use

When given a RUNE spec and a list of target languages, generate an implementation + test file for each language, ensuring all implementations produce identical behavior.

Input: a RUNE spec + list of target languages. Output: one implementation file + one test file per language.

Language Adaptation

Any programming language is supported. When generating for a target language, adapt:

• Naming convention — follow the language's standard (snake_case, camelCase, PascalCase, etc.)
• Error handling — use the language's idiomatic mechanism (exceptions, error returns, Result types, pattern matching)
• Testing framework — use the language's standard or most common framework
• Type system — map types to native equivalents

Process

Step 1: Analyze the Spec

Read the RUNE spec and extract:

• Function purpose (from INTENT)
• Input/output contract (from SIGNATURE, even if language-specific)
• All behavior rules (from BEHAVIOR)
• All test cases (from TESTS)
• Constraints and edge cases

Step 2: Adapt Signature Per Language

Convert the SIGNATURE to each target language's syntax and conventions.

From a spec with:

SIGNATURE: |
  def calculate_discount(price: float, percentage: int) -> float

Generate:

Adaptation rules:

• Follow each language's naming convention (snake_case, camelCase, PascalCase)
• Map types to native equivalents (float -> f64, number, double)
• Add error return channels where idiomatic (Go returns error, Rust returns Result)
• Use the language's exception/error mechanism for BEHAVIOR error rules

Step 3: Adapt Error Handling

Each language handles errors differently. Adapt the BEHAVIOR error rules:

Preserve the exact error messages across all languages.

Step 4: Generate Implementations

For each language, generate the implementation following these rules:

• Implement ALL BEHAVIOR rules in order
• Use idiomatic patterns for the target language
• Preserve the logic flow from the spec
• Match error messages exactly
• Handle all EDGE_CASES
• Add a docstring/comment from INTENT

Step 5: Generate Tests

For each language, generate a complete test file:

• Convert every TESTS entry to the language's test framework
• Expand [...] into concrete fixtures per language
• Use language-idiomatic assertion style
• Group tests by category (happy path, boundary, error)

Step 6: Cross-Language Verification Table

After generating all implementations, produce a verification table:

## Cross-Language Verification
 
| Test Case | Python | TypeScript | Go | Rust |
|-----------|--------|------------|-----|------|
| `(100.0, 20) -> 80.0` | `calculate_discount(100.0, 20)` | `calculateDiscount(100.0, 20)` | `CalculateDiscount(100.0, 20)` | `calculate_discount(100.0, 20)` |
| `(-10.0, 20) -> error` | `raises ValueError` | `throws Error` | `returns error` | `returns Err` |
| ... | ... | ... | ... | ... |
 
All implementations must produce **identical outputs** for identical inputs.
Error messages must be **character-for-character identical** across languages.

Output Structure

Generate files organized by language:

<function_name>/
├── python/
│   ├── <function_name>.py
│   └── test_<function_name>.py
├── typescript/
│   ├── <function_name>.ts
│   └── <function_name>.test.ts
├── go/
│   ├── <function_name>.go
│   └── <function_name>_test.go
└── VERIFICATION.md          # cross-language verification table

Or if adding to an existing project, follow the project's directory structure.

Type Mapping Reference

Common mappings for popular languages. Any language is supported — adapt types to its native equivalents following the same pattern.

For languages not listed (C#, Ruby, Swift, Kotlin, Elixir, Haskell, PHP, etc.), map each type to its closest native equivalent.

Rules

• All implementations must pass the same logical tests
• Error messages must be identical across languages (same string)
• Use idiomatic patterns per language — do not write "Python in Go"
• If a RUNE feature cannot be directly expressed in a language (e.g., tuples in Java), use the closest idiomatic equivalent and document the adaptation
• Always generate the cross-language verification table
• If the spec has language: <specific>, ask the user which additional languages they want
• If the spec has language: any, ask the user which languages to target (or default to Python + TypeScript)