123 lines
6.5 KiB
Markdown
123 lines
6.5 KiB
Markdown
# Claro Roadmap
|
|
|
|
Current release: **Claro v1.18.26**
|
|
|
|
Claro is now in the stable v1 development line. Older RC milestones are kept as historical notes in files such as `RC0_NOTES.md`, `RC3_NOTES.md`, and `RC9_VALIDATION.md`; they are not the current roadmap.
|
|
|
|
## Current direction
|
|
|
|
Keep Claro beginner-first while growing into a complete small programming platform:
|
|
|
|
- readable syntax before clever syntax
|
|
- friendly diagnostics before advanced compiler features
|
|
- safe local/offline defaults before networked behavior
|
|
- small features that are easy to teach, test, and document
|
|
- normal feature releases inside the v1 line; reserve v2 for a future full rewrite
|
|
|
|
## v1.18.26 status snapshot
|
|
|
|
See `CURRENT_STATUS.md` for the detailed feature matrix.
|
|
|
|
- Beginner scripting core: stable foundation
|
|
- Objects/classes: foundation present; needs polish and stronger type checks
|
|
- Package workflow: local foundation present; registry and publishing not complete
|
|
- Networking: HTTP client foundation present; beginner web server not complete
|
|
- Concurrency: deterministic task foundation; native threads not exposed as beginner API
|
|
- Static typing: variables and containers foundation; function/object/import typing incomplete
|
|
- IDE support: metadata/helper foundation; full editor/LSP experience incomplete
|
|
- Graphics/SDL: experimental/planned; not enabled in the stable executable
|
|
|
|
## Near-term cleanup priorities
|
|
|
|
1. Keep beginner-facing docs current and separate from historical release notes.
|
|
2. Keep examples aligned with the modern simple syntax (`END`, `DO`, short `SET`, short `ASK`) while documenting older compatibility forms separately.
|
|
3. Expand validation around typecheck diagnostics and package/networking safety. Current Forgejo/Gitea CI runs the documented release gates (`claro validate`, typecheck diagnostics validation, version convention validation, and CI workflow coverage validation). Current package safety validation covers safe project creation, rejecting unsafe project names during `claro new`, safe manifest/lockfile creation, rejecting unsafe package names during `package add`, detecting unsafe package names already present in `claro.project` during `package doctor`, refusing to write lockfile data for unsafe package names during `package lock`, and making `package remove` fail instead of reporting success when unsafe package names remain during lockfile refresh. Current function validation covers correct checked calls, wrong-type arguments, missing checked-argument diagnostics, missing unchecked-argument diagnostics for simple functions in both modern `DO greet` and empty compatibility `CALL greet WITH` forms, extra-argument diagnostics, and beginner-facing unknown-function diagnostics for mistyped modern `DO` and compatibility `CALL ... WITH` calls; current object-method parameter validation covers correct modern `DO object.method ...` and compatibility `CALL object.method WITH ...` checked calls, wrong-type diagnostics for both call forms, checked methods after another method in the same class, missing and extra checked-argument diagnostics including the extra-argument case for a checked method after another method in the same class, missing unchecked-argument diagnostics for simple object methods, missing-object guidance when `DO player.method ...` or compatibility `CALL object.method WITH ...` appears before `NEW` even if the method name is also wrong, and class-specific unknown-method diagnostics for both modern and compatibility calls when a learner calls a method the class does not declare; object-field validation covers correct NUMBER, TEXT, and YESNO direct `SET object.field value` assignments, direct `CHECK TYPE` metadata acceptance for NUMBER/TEXT/YESNO fields, negative NUMBER/TEXT/YESNO metadata mismatches, NUMBER/TEXT/YESNO-expectation unknown-field `CHECK TYPE` diagnostics, missing-object `CHECK TYPE` and direct field assignment diagnostics, NUMBER/TEXT/YESNO wrong-type diagnostics, field collection after simple methods, NUMBER/TEXT/YESNO-valued unknown-field diagnostics, and beginner-facing fallback wording when an unknown-field assignment expression type is not inferable yet.
|
|
4. Add small examples for each foundation feature before adding bigger syntax.
|
|
|
|
## Complete-platform milestones
|
|
|
|
### 1. Strong static types
|
|
|
|
Goal: make larger beginner programs safer without making first scripts harder.
|
|
|
|
Needed next:
|
|
- richer typed function signatures
|
|
- typed function returns
|
|
- type checking across branches and loops
|
|
- typed imports/modules
|
|
- broader object field checking and method return typing
|
|
- clearer error messages for type mismatches
|
|
|
|
### 2. Objects and classes polish
|
|
|
|
Goal: keep object-oriented examples readable enough for beginners.
|
|
|
|
Needed next:
|
|
- constructor-style defaults or beginner-friendly initialization helpers
|
|
- method return checks
|
|
- object printing/debugging helpers
|
|
- better examples that avoid abstract toy OOP
|
|
|
|
### 3. Package manager and registry
|
|
|
|
Goal: make sharing beginner libraries safe and predictable.
|
|
|
|
Needed next:
|
|
- local package install from a folder
|
|
- version constraints
|
|
- package export/publish format
|
|
- lock-file verification
|
|
- remote registry design with checksums/signatures before downloads
|
|
|
|
### 4. Networking and web apps
|
|
|
|
Goal: allow safe beginner networking and small local web apps.
|
|
|
|
Needed next:
|
|
- beginner web server syntax
|
|
- routes
|
|
- request/response helpers
|
|
- local-only safe default mode
|
|
- examples that work offline or on localhost
|
|
|
|
### 5. Tasks, concurrency, and possible threads
|
|
|
|
Goal: teach concurrency as safe tasks first, not low-level thread hazards.
|
|
|
|
Needed next:
|
|
- cooperative scheduler semantics
|
|
- cancellation
|
|
- timeouts
|
|
- message passing or channels
|
|
- explicit decision on whether native threads are needed later
|
|
|
|
### 6. IDE/editor support
|
|
|
|
Goal: give beginners fast feedback in their editor.
|
|
|
|
Needed next:
|
|
- syntax highlighting grammar
|
|
- editor extension packaging
|
|
- hover/help text
|
|
- go-to-definition where practical
|
|
- code actions for common mistakes
|
|
- LSP server after metadata and diagnostics stabilize
|
|
|
|
### 7. Graphics and SDL
|
|
|
|
Goal: make visual/game examples possible without making the portable stable build fragile.
|
|
|
|
Needed next:
|
|
- keep placeholder graphics commands beginner-safe
|
|
- define optional SDL build flag/backend
|
|
- add graceful errors when graphics are unavailable
|
|
- document which examples require experimental builds
|
|
|
|
## Documentation rule
|
|
|
|
Every new feature should update three places before it is treated as release-ready:
|
|
|
|
1. `README.md` or the relevant feature doc for beginner-facing usage
|
|
2. `CURRENT_STATUS.md` for status and limitations
|
|
3. a validation note or test command showing how it was checked
|