Guidelines for PRs

Thank you for contributing to Luma. These guidelines help keep the codebase consistent and make reviews smoother.

Before you start

1. Check existing issues to see if someone is already working on the same thing
2. Open an issue first for larger changes to discuss the approach
3. Fork the repository and create a feature branch from main

Branch naming

Use descriptive branch names:

feature/set-difference-method
fix/optional-comparison-crash
docs/update-collections-page

Making changes

Code changes

• Follow existing naming conventions (_luma_* for core functions, snake_case for Luma code)
• Keep changes focused: one feature or fix per PR
• Add or update tests when changing compiler behavior
• Run go test ./... before submitting

Core runtime changes (.lcore files)

• Include the standard function header comment (see How to Contribute)
• Regenerate the core after changes: go run ./cmd/coregen -in ./core -out ./internal/core/core_gen.go
• Verify the build: go build -o luma .

Documentation changes

• Keep the tone clear and concise
• Include code examples where possible
• Verify the Hugo site builds cleanly

Commit messages

Write clear, descriptive commit messages:

Add set difference method for float type

Implements _luma_set_difference_float in core runtime
and wires it into the compiler dispatch.

• Use imperative mood (“Add”, not “Added”)
• First line should be under 72 characters
• Add detail in the body if needed

Pull request format

When opening a PR, include:

• What changed and why
• How to test the change (example Luma code or test commands)
• Any known limitations or follow-up work needed

Review process

• PRs are reviewed for correctness, clarity, and consistency with Luma’s design philosophy
• Small, focused PRs are reviewed faster than large ones
• Be open to feedback: Luma values simplicity, and reviewers may suggest simpler approaches
• All existing tests must pass before merge

What makes a good PR

• Solves one clearly defined problem
• Includes tests or example code demonstrating the change
• Follows existing patterns in the codebase
• Has a clear commit history
• Doesn’t introduce unnecessary complexity