# Contributing

ENG is organized as a small Rust interpreter. Changes are easiest to review when they are limited to the subsystem they actually affect.

## Typical workflow

1. Make a change.
2. Run `cargo fmt`.
3. Run `cargo test`.
4. Run a relevant example with `cargo run -- run ...`.
5. Update the documentation if syntax or runtime behavior changed.

## Adding syntax

A new language construct generally involves:

1. adding or adjusting a `TokenKind`
2. teaching the lexer to recognize the words
3. adding parser logic
4. adding an AST variant if needed
5. compiling the AST to bytecode
6. adding VM/runtime behavior
7. adding tests
8. documenting the syntax

Do not add a keyword if an identifier can safely represent the same concept.

## Parser changes

ENG uses a handwritten recursive-descent parser. Keep new grammar forms explicit and unambiguous.

Every new statement should have a clear terminating period and block constructs should have a clear `End.` boundary.

## Runtime changes

Runtime errors should use `EnglingError::runtime(...)` so they remain consistent with the existing error system.

Module problems should use `EnglingError::module(...)`.

## UI changes

GUI functionality is behind the `ui` Cargo feature. Avoid making the default interpreter depend on the GUI path.

## Documentation

When changing syntax, update both the grammar/reference documentation and at least one runnable example.