Repository navigation
nlsc lint — Semantic Linter #94
Description
Description
Linting in NLS is not about code style — it's about intent quality.
The linter checks whether specifications are complete, consistent, and safe before they ever become code. This is semantic linting, not cosmetic linting.
Lint Rules
Structural Completeness:
- 🚩 Function missing PURPOSE
- 🚩 Function has INPUTS but no GUARDS
- 🚩 Function has INPUTS but no tests
- 🚩 Custom type defined without invariants
Safety Checks:
- 🚩 Division used but no zero guard
- 🚩 List indexing without bounds consideration
- 🚩 Optional type unwrapped without nil check
Consistency:
- 🚩 Function name doesn't match PURPOSE statement
- 🚩 Test exists but doesn't cover failure case
- 🚩 Guard references undefined type
- 🚩 DEPENDS lists function that doesn't exist
Best Practices:
- 🚩 LOGIC steps exceed 10 (consider decomposition)
- 🚩 Deeply nested conditionals
- 🚩 Duplicated guard conditions across functions
CLI
nlsc lint file.nl # lint single file
nlsc lint src/ # lint directory
nlsc lint . --strict # treat warnings as errors
nlsc lint . --fix # auto-fix where possible (formatting, ordering)Acceptance Criteria
-
nlsc lintruns all structural completeness checks -
nlsc lintruns all safety checks - Output shows file, line, rule ID, message
-
--strictmode for CI (exit 1 on any warning) - Rules are configurable via
nls.tomlor.nlslintrc - At least 10 rules implemented at launch
Integration
- LSP reports lint warnings as diagnostics (yellow squiggles)
- VS Code extension shows lint on save
- GitHub Action includes lint step
Why This Matters
Your thesis: "Lift meaning up, push mechanics down."
If meaning is the primary artifact, meaning needs its own quality tooling — not borrowed Python linters.
Without lint: NLS becomes "pretty English that varies wildly by author."
With lint: NLS becomes a disciplined, reviewable language of intent.
Activity