Every Vera program that uses Result, Option, or UrlParts must locally redefine the ADT to access its constructors for pattern matching:
private data Result<T, E> { Ok(T), Err(E) }
private data Option<T> { None, Some(T) }
This is 2–6 lines of identical boilerplate in every program. All 9 examples that use these types include these definitions. The v0.0.88 viability assessment flags this as boilerplate that agents "will almost certainly forget" — the type checker registers the built-in constructors (environment.py lines 145–200) but the local data declaration is still required for pattern matching.
Design tension
Goal 2 (explicitness over convenience) argues against implicit imports. But this boilerplate adds no information — every definition is identical, and omitting it produces a confusing error rather than a useful explicitness signal.
Options to consider
- Implicit prelude —
Result, Option, and their constructors are always available without declaration (like Rust's std::prelude). Simplest for agents, least explicit.
- Auto-import from
vera.collections — the module vera/collections.vera already defines these types publicly. Making it auto-imported would provide the constructors without local redefinition.
- Built-in constructor resolution — extend the checker so that constructors registered via
environment.py are directly usable in patterns without a local data block. The type is already registered; only the constructor names are inaccessible.
- Status quo with better docs — keep the redefinition requirement but improve SKILL.md templates to always include the boilerplate.
The vera.collections module already exists (examples/vera/collections.vera) and defines Option and Result publicly. A prelude that auto-imports this module would reuse existing infrastructure.
Cross-references
Every Vera program that uses
Result,Option, orUrlPartsmust locally redefine the ADT to access its constructors for pattern matching:This is 2–6 lines of identical boilerplate in every program. All 9 examples that use these types include these definitions. The v0.0.88 viability assessment flags this as boilerplate that agents "will almost certainly forget" — the type checker registers the built-in constructors (
environment.pylines 145–200) but the localdatadeclaration is still required for pattern matching.Design tension
Goal 2 (explicitness over convenience) argues against implicit imports. But this boilerplate adds no information — every definition is identical, and omitting it produces a confusing error rather than a useful explicitness signal.
Options to consider
Result,Option, and their constructors are always available without declaration (like Rust'sstd::prelude). Simplest for agents, least explicit.vera.collections— the modulevera/collections.veraalready defines these types publicly. Making it auto-imported would provide the constructors without local redefinition.environment.pyare directly usable in patterns without a localdatablock. The type is already registered; only the constructor names are inaccessible.The
vera.collectionsmodule already exists (examples/vera/collections.vera) and definesOptionandResultpublicly. A prelude that auto-imports this module would reuse existing infrastructure.Cross-references