This repository is the designated home for the future normative Cretes specification and for the requirements that constrain it. No language semantics, grammar or syntax have been approved or implemented.
| Phase | Status | Output in this repository |
|---|---|---|
| Phase 0 — Project foundation and governance | Foundation established; administrative dependencies tracked | Repository scaffold and change-control policy (below) |
| Phase 1 — Language vision, requirements and design principles | Baseline published | docs/ — vision, principles, requirements, v0.1 scope, Phase 2 questions |
| Phase 2 — Architecture | Proposed; RFC review pending | 30 architecture records, requirement traceability, v0.1 blueprint |
| Phase 3 — Language surface | Draft candidate; acceptance pending | 40 sections, grammar and examples, traceability, validation |
Phase 1 defines what Cretes must accomplish. Phase 2 and later phases decide how. The Phase 1 documents are requirements. They are not normative language rules and do not define syntax.
The architecture proposal covers sections 2.1–2.30. All choices remain PROPOSED, pending the RFC process and its final-comment period. Publication is not acceptance, implementation or release. Tracking issue. The issue is administratively closed; formal acceptance remains pending in RFC review.
The language candidate addresses sections 3.1–3.40 with proposed syntax, 14 examples, formal grammar, 257 requirement mappings and an isolated experimental recognizer. Read the completion report, review record and v0.1 acceptance checklist. Tracking issue.
This candidate is PROPOSED / UNACCEPTED, not frozen or released. Its syntax and lexical checks do not establish semantic correctness. Architecture and syntax acceptance remain separate governance decisions. Phase 4 and production compiler/runtime implementation have not started.
Read in this order:
- Vision — what Cretes is, why it exists, the long-term ecosystem.
- Target developers — the six personas Cretes is designed for.
- Design principles — the fifteen principles that guide every decision.
- Requirements framework — MUST/SHOULD/MAY terminology, requirement IDs, layers, targets, traceability.
- Use cases — concrete scenarios traced to requirements.
- The domain and cross-cutting requirements (tables below).
- v0.1 requirements — the first language milestone.
- Phase 2 open questions — architecture decisions deliberately left open.
docs/
├── vision/ VISION.md, TARGET-USERS.md
├── principles/ DESIGN-PRINCIPLES.md
├── requirements/ README.md (framework), USE-CASES.md, CORE.md, SAFETY.md,
│ │ PERFORMANCE.md, CONCURRENCY.md, INTEROPERABILITY.md,
│ │ PLATFORMS.md, NON-GOALS.md, V0.1-REQUIREMENTS.md
│ └── domains/ automation.md, networking.md, ai-ml.md, cybersecurity.md
├── reviews/ PHASE-1-REVIEW.md
└── PHASE-2-OPEN-QUESTIONS.md
Future normative chapters will cover the areas below. They will be kept separate from the Phase 1 requirements in docs/, and their location will be decided when the first chapter is approved.
| Area | Future document scope |
|---|---|
| Lexical structure and grammar | Source encoding, tokens and formal grammar |
| Types and semantics | Values, conversions, inference and semantic constraints |
| Expressions and control flow | Evaluation, branching, loops and functions |
| Modules | Imports, visibility and module identity |
| Errors and resources | Failure behavior, memory and resource lifetime |
| Concurrency | Execution and synchronization rules |
| Standard library | Required behavior of standard interfaces |
| Conformance | Requirements and positive/negative test mappings |
These headings do not select any design. Chapters are added after approved proposals. Each chapter should cite the requirement IDs it satisfies.
An accepted RFC records a design decision. A reviewed specification change defines normative behavior. Tutorials and examples are explanatory. A compiler discrepancy is not automatically a change to the language. Resolve it in an issue with the specification reference and test evidence.
Each future chapter should declare:
- status and scope;
- terminology;
- normative rules and their rationale;
- examples, marked as normative or illustrative;
- links to accepted RFCs and conformance tests.
Drafts must remain visibly marked. Version the specification and associate it with toolchain releases before making stability claims.
Phase 1 requirements change through issues and reviewed pull requests. Adding, weakening or removing a MUST requirement requires an RFC. See Changing requirements.
License: Apache-2.0.