Add language support roadmap and feature requests
This commit is contained in:
@@ -71,3 +71,40 @@
|
||||
- Phase 7f: Session recording pipeline — capture, anonymize, export (Steps 230–234)
|
||||
|
||||
---
|
||||
## PHP Language Support (Full Pipeline) — PROPOSED
|
||||
|
||||
**Goal:** Add full PHP support (parse, AST, generate, project, and annotations) to Whetstone.
|
||||
|
||||
**Scope:**
|
||||
- Tree-sitter PHP parser integration
|
||||
- PHP AST mapping to SemAnno concepts
|
||||
- PHP generator with annotation-aware output
|
||||
- Cross-language projection to/from PHP
|
||||
- Tests: parse/generate round-trip, annotation preservation, projection matrix coverage
|
||||
|
||||
**Notes:**
|
||||
- Start with core PHP syntax (functions, classes, namespaces, arrays, exceptions, traits).
|
||||
- WordPress-specific libraries on top of core PHP support.
|
||||
|
||||
---
|
||||
|
||||
## WordPress Support (Library + Semantics) — PROPOSED
|
||||
|
||||
**Goal:** Enable WordPress-aware tooling on top of PHP support.
|
||||
|
||||
**Scope:**
|
||||
- Library symbol stubs for WordPress core APIs
|
||||
- Semantic tags for WP concepts (hooks, filters, actions)
|
||||
- Agent suggestions for safe WP patterns
|
||||
|
||||
---
|
||||
|
||||
## Rust Plugin Packaging (Conflict Resolver) — PROPOSED
|
||||
|
||||
**Goal:** Package a Rust-based topological conflict resolver as a Whetstone plugin.
|
||||
|
||||
**Scope:**
|
||||
- Define plugin interface for external tools
|
||||
- Packaging format and plugin discovery/loading
|
||||
- Example integration with a Rust binary or shared library
|
||||
|
||||
|
||||
71
LANGUAGE_SUPPORT_ROADMAP.md
Normal file
71
LANGUAGE_SUPPORT_ROADMAP.md
Normal file
@@ -0,0 +1,71 @@
|
||||
# Language Support Roadmap
|
||||
|
||||
This document proposes an order of language support additions based on
|
||||
semantic fit for AST-driven workflows, ecosystem impact, and projection
|
||||
complexity. It is intended for future sprint planning (not tied to Sprint 8).
|
||||
|
||||
## Principles
|
||||
- Semantic Fit: Languages with clean, well-defined ASTs and predictable semantics.
|
||||
- Ecosystem Impact: Practical value from large ecosystems and real-world usage.
|
||||
- Projection Complexity: How hard it is to preserve semantics across languages.
|
||||
|
||||
## Proposed Phases
|
||||
|
||||
### Phase A: High-Impact Ecosystem Coverage
|
||||
1. PHP (core language)
|
||||
- Rationale: Large installed base, web dominance, WordPress ecosystem.
|
||||
- Complexity: Medium (dynamic typing, mixed paradigms).
|
||||
- Notes: Add WordPress stubs and semantic tags after core PHP support.
|
||||
|
||||
2. C#
|
||||
- Rationale: Enterprise usage, strong typing, tooling clarity.
|
||||
- Complexity: Medium (runtime / reflection surface).
|
||||
|
||||
3. Kotlin
|
||||
- Rationale: JVM + Android, modern semantics, good tooling.
|
||||
- Complexity: Medium (interop with Java).
|
||||
|
||||
### Phase B: Semantic-First Languages (Best AST Fit)
|
||||
4. Common Lisp / Scheme
|
||||
- Rationale: Homoiconic AST, macros, direct mapping to transformations.
|
||||
- Complexity: Medium (macro system and evaluation model).
|
||||
|
||||
5. OCaml / F#
|
||||
- Rationale: Algebraic data types, pattern matching, strong typing.
|
||||
- Complexity: Medium (type system mapping).
|
||||
|
||||
6. Haskell
|
||||
- Rationale: Pure FP, strong types; great for semantic transformations.
|
||||
- Complexity: High (typeclass system, laziness).
|
||||
|
||||
### Phase C: Concurrency/Logic Models
|
||||
7. Erlang / Elixir
|
||||
- Rationale: Actor model, supervision trees; great for explicit execution annotations.
|
||||
- Complexity: High (message passing semantics).
|
||||
|
||||
8. Prolog
|
||||
- Rationale: Declarative semantics, unification; fits AST reasoning.
|
||||
- Complexity: High (search/backtracking model).
|
||||
|
||||
### Phase D: Long-Tail, Specialized
|
||||
9. Swift
|
||||
- Rationale: ARC semantics align with annotations; Apple ecosystem.
|
||||
- Complexity: High (toolchain + platform APIs).
|
||||
|
||||
10. Ruby / Lua
|
||||
- Rationale: Dynamic languages with distinct semantics.
|
||||
- Complexity: Medium.
|
||||
|
||||
11. Dart
|
||||
- Rationale: Flutter ecosystem.
|
||||
- Complexity: Medium.
|
||||
|
||||
## WordPress Layer (Post-PHP)
|
||||
- Add WordPress core API stubs.
|
||||
- Introduce semantic tags for hooks, filters, actions.
|
||||
- Provide guidance for safe/idiomatic WP patterns.
|
||||
|
||||
## Notes on Projection Strategy
|
||||
- Use LangSpecific annotations to preserve constructs that do not map cleanly.
|
||||
- Define a minimal “semantic core” for each language and expand iteratively.
|
||||
- Validate with projection matrix tests as language count grows.
|
||||
Reference in New Issue
Block a user