Contributing

How a change moves through Venutian's compiler, runtime and standard library, and how to reach the team.

Venutian's source is closed, and the discipline behind every change is still worth documenting: it is what keeps every claim on this site honest, and it is the same discipline a collaborator working with the team follows.

How a language level change moves

A change to the language itself, a new keyword or construct, touches the same stack in order every time: the vocabulary decision first (is this word or construct earning its place, the way every existing keyword had to), the formal grammar next, then the lexer if it introduces a new token, the parser, the semantic analysis pass for any rule the grammar alone cannot express, code generation, a new bytecode opcode if one is needed, and the virtual machine. A change is not finished until it has a test and a new or updated file under examples/, since every example in that directory is executed by the conformance suite as proof that the feature actually runs.

Two layers of standard library

Adding capability to Venutian does not usually mean touching the compiler at all. The standard library is two distinct layers. The first is the always available core builtins, functions that need no use at all; a new one has to earn a permanent reservation against every future Venutian program's names, so it is not a casual addition. The second layer is the importable stdlib/, dozens of .ven files, each one brought in by name with use, written entirely in Venutian itself, with no compiler or runtime change required. New capability belongs here by default: interpreter hook plumbing, the narrow cases where a .ven file needs a small native primitive underneath it, is the accepted exception, not the starting point.

Testing

venutian test

runs the full conformance suite, covering the lexer, parser, semantic analysis, bytecode, the virtual machine and its error paths, the object system, exceptions, pattern matching, modules, the REPL, and the standard library, one file per concern. Writing a new test means adding a case to the file matching its concern, or, for a feature big enough to deserve one, a new .ven file under examples/.

Style

Code examples and documentation follow one voice throughout: type names are written exactly as kind() reports them (Integer, Text, Truth, and the rest), sections favor an affirmative tone describing what the language does rather than a list of what to avoid, and security relevant behavior is gathered into its own section rather than scattered as warnings through unrelated pages.

Reach the team

Bug reports, security reports, and proposals for a language level change all go through the same door: see Community for the address and what to include.