[Fikir] v1 → v2 Ekosistem Yol Haritası — Derleyici Bittikten Sonraki Bağımlılık Sırası #111

New Issue

saqut · 2026-06-14T22:38:39+03:00

saqut commented

2026-06-14 22:38:39 +03:00

Giriş (Nedir, Neden Önemli?)

#91 (LSP) ve #107 (CLI) artık "derleyici bittiğinde ne lazım" sorusuna katmanlı (Tier) cevaplar veriyor. Ama bu issue'lar birbirinden, #93 (fmt), #94 (time-travel debug), #95 (playground), #96 (test bloğu) ve #97 (paket yöneticisi)'den bağımsız okunursa, hangisinin hangisine bağımlı olduğu, hangi sıraya göre yapılırsa en az tekrar-iş (rework) çıkacağı kaybolur. Bu issue, "derleyici (Faz 0-4 + IR/VM) tamamlandı, artık ekosistemi inşa ediyoruz" senaryosunda bağımlılık sırasını tek bir yerde toplar — bir "v1 → v2 yol haritası".

Aşama A — "Derleyici bitti" anında neredeyse bedava gelenler

Bunlar, Faz 0-4'ün verilerini (Symbol Table, DiagnosticEngine, AST) farklı bir şekilde göstermekten ibarettir — yeni analiz gerektirmezler:

saqut check (#107 Tier 0)
saqut explain <kod> (#107 Tier 1)
LSP Tier 1: diagnostics, hover, go-to-definition, completion (#91)
saqut ast --format=tree/dot/table (#106)

→ Önerilen ilk hafta: Bunların hepsi paralel, küçük PR'lar olarak yapılabilir; aralarında bağımlılık yok.

Aşama B — Tek bir mimari önkoşula bağlı olanlar: "Artımlı / Gömülebilir Derleyici"

LSP Tier 1-2 (#91), saqut watch (#107), ve saqut repl (#107 Tier 1) hepsi aynı şeyi istiyor: derleyicinin C++ sınıflarının (Lexer, Parser, SymbolTable, DiagnosticEngine, ileride VM) tek seferlik CLI çağrısı dışında, uzun ömürlü bir süreçte tekrar tekrar, kısmi girdilerle çağrılabilmesi.

→ Bu, "ekosistem" aşamasının TEK BÜYÜK mimari yatırımı. Bir kere yapılırsa Aşama A'nın Tier 2'leri (LSP references/rename, watch, repl) art arda ve hızlı gelir. Yapılmazsa her biri kendi geçici/yavaş çözümünü icat eder ve sonra hepsi yeniden yazılır.

Aşama C — Modül sistemine bağlı olanlar

#81-83 (import/modüller) bitmeden şunlar eksik kalır:

LSP Tier 4: workspace/symbol, cross-file rename/references (#91)
saqut build (#107 Tier 2) — "proje" kavramı modülsüz anlamsız
saqut pkg (#97) — paket = modül koleksiyonu

→ Modül sistemi, ekosistem issue'larının ikinci büyük bağımlılık noktası.

Aşama D — VM'in "adım-adım çalışma" API'sine bağlı olanlar

#94 (zaman-yolculuğu debug) ve LSP Tier 4 DAP entegrasyonu (#91) aynı temel özelliği istiyor: VM'in step() / "bir IR komutu çalıştır, durumu döndür" şeklinde çağrılabilmesi.

→ IR/VM tasarımı (#74-78) sırasında bu API baştan düşünülürse (VM'in run()'ı zaten içeride step()'i döngüde çağırıyor olsun), hem #94 hem DAP (#91 Tier 4) bunun üzerine ince katmanlar olarak gelir. Sonradan eklenirse VM'in dispatch döngüsü (#77) yeniden yazılır.

Aşama E — Bağımsız / paralel yürüyebilenler (istenen an eklenebilir)

saqut fmt (#93) — sadece AST + (yorum-koruma çözümü) gerektirir, yukarıdaki hiçbir aşamaya bağlı değil.
Syntax highlighting (#92) — tokenizer'dan üretilebilir, derleyicinin geri kalanından bağımsız.
Dil-içi test{} bloğu (#96) — assert builtin'i (#89) yeterli, modül/LSP'ye bağımlı değil.
WASM playground (#95) — derleyici çekirdeği tamamlandığı anda, Emscripten ile bağımsız bir iş.

Önerilen Genel Sıra (özet)

Faz 0-4 + IR/VM (mevcut roadmap)
        │
        ├─► Aşama A (bedava kazanımlar: check/explain/hover/definition/format)
        │
        ├─► Aşama E (paralel: fmt, syntax highlight, test{}, playground)
        │
        ▼
   Aşama B (artımlı/gömülebilir derleyici mimarisi)
        │
        ├─► LSP Tier 2 (references/rename/watch/repl)
        │
        ├─► Aşama C (modül sistemi → build/pkg/workspace-symbol)
        │
        └─► Aşama D (VM step() API → time-travel debug + DAP)

Açık Sorular

Bu sıralama "zorunlu" değil — örn. modül sistemi (#81-83) erken talep edilirse Aşama C öne çekilebilir. Amaç, "hangi iş hangi mimari yatırımı gereksiz yere tekrarlatır" sorusuna karşı bir kontrol listesi olmak.
Aşama B'deki "gömülebilir derleyici" kararı, Faz 2-3 sınıflarının (SymbolTable, DiagnosticEngine) API tasarımına şimdiden not düşülmeli mi (örn. "bu sınıf bir kere oluşturulup birden çok analyze() çağrısı arasında state tutabilmeli")? Bu, geriye dönük en maliyetli değişikliklerden biri olur.

İmza/Yorum: Bu issue bir "yapılacak iş" değil, bir harita — #91, #93-98, #107 arasındaki gizli bağımlılıkları görünür kılmak için. Her aşama tamamlandığında bu harita güncellenmeli.

### Giriş (Nedir, Neden Önemli?) #91 (LSP) ve #107 (CLI) artık "derleyici bittiğinde ne lazım" sorusuna katmanlı (Tier) cevaplar veriyor. Ama bu issue'lar birbirinden, #93 (fmt), #94 (time-travel debug), #95 (playground), #96 (test bloğu) ve #97 (paket yöneticisi)'den **bağımsız** okunursa, hangisinin hangisine **bağımlı** olduğu, hangi sıraya göre yapılırsa en az tekrar-iş (rework) çıkacağı kaybolur. Bu issue, "derleyici (Faz 0-4 + IR/VM) tamamlandı, artık ekosistemi inşa ediyoruz" senaryosunda **bağımlılık sırasını** tek bir yerde toplar — bir "v1 → v2 yol haritası". --- ### Aşama A — "Derleyici bitti" anında neredeyse bedava gelenler Bunlar, Faz 0-4'ün verilerini (Symbol Table, DiagnosticEngine, AST) **farklı bir şekilde göstermekten** ibarettir — yeni analiz gerektirmezler: - `saqut check` (#107 Tier 0) - `saqut explain <kod>` (#107 Tier 1) - LSP Tier 1: diagnostics, hover, go-to-definition, completion (#91) - `saqut ast --format=tree/dot/table` (#106) → **Önerilen ilk hafta:** Bunların hepsi paralel, küçük PR'lar olarak yapılabilir; aralarında bağımlılık yok. --- ### Aşama B — Tek bir mimari önkoşula bağlı olanlar: "Artımlı / Gömülebilir Derleyici" LSP Tier 1-2 (#91), `saqut watch` (#107), ve `saqut repl` (#107 Tier 1) **hepsi aynı şeyi** istiyor: derleyicinin C++ sınıflarının (Lexer, Parser, SymbolTable, DiagnosticEngine, ileride VM) **tek seferlik CLI çağrısı dışında**, uzun ömürlü bir süreçte tekrar tekrar, kısmi girdilerle çağrılabilmesi. → **Bu, "ekosistem" aşamasının TEK BÜYÜK mimari yatırımı.** Bir kere yapılırsa Aşama A'nın Tier 2'leri (LSP references/rename, watch, repl) **art arda ve hızlı** gelir. Yapılmazsa her biri kendi geçici/yavaş çözümünü icat eder ve sonra hepsi yeniden yazılır. --- ### Aşama C — Modül sistemine bağlı olanlar #81-83 (import/modüller) bitmeden şunlar **eksik** kalır: - LSP Tier 4: `workspace/symbol`, cross-file rename/references (#91) - `saqut build` (#107 Tier 2) — "proje" kavramı modülsüz anlamsız - `saqut pkg` (#97) — paket = modül koleksiyonu → Modül sistemi, ekosistem issue'larının **ikinci büyük bağımlılık noktası**. --- ### Aşama D — VM'in "adım-adım çalışma" API'sine bağlı olanlar #94 (zaman-yolculuğu debug) ve LSP Tier 4 DAP entegrasyonu (#91) **aynı temel özelliği** istiyor: VM'in `step()` / "bir IR komutu çalıştır, durumu döndür" şeklinde çağrılabilmesi. → IR/VM tasarımı (#74-78) sırasında bu API **baştan** düşünülürse (VM'in `run()`'ı zaten içeride `step()`'i döngüde çağırıyor olsun), hem #94 hem DAP (#91 Tier 4) bunun üzerine ince katmanlar olarak gelir. Sonradan eklenirse VM'in dispatch döngüsü (#77) yeniden yazılır. --- ### Aşama E — Bağımsız / paralel yürüyebilenler (istenen an eklenebilir) - `saqut fmt` (#93) — sadece AST + (yorum-koruma çözümü) gerektirir, yukarıdaki hiçbir aşamaya bağlı değil. - Syntax highlighting (#92) — tokenizer'dan üretilebilir, derleyicinin geri kalanından bağımsız. - Dil-içi `test{}` bloğu (#96) — `assert` builtin'i (#89) yeterli, modül/LSP'ye bağımlı değil. - WASM playground (#95) — derleyici çekirdeği tamamlandığı anda, Emscripten ile bağımsız bir iş. --- ### Önerilen Genel Sıra (özet) ``` Faz 0-4 + IR/VM (mevcut roadmap) │ ├─► Aşama A (bedava kazanımlar: check/explain/hover/definition/format) │ ├─► Aşama E (paralel: fmt, syntax highlight, test{}, playground) │ ▼ Aşama B (artımlı/gömülebilir derleyici mimarisi) │ ├─► LSP Tier 2 (references/rename/watch/repl) │ ├─► Aşama C (modül sistemi → build/pkg/workspace-symbol) │ └─► Aşama D (VM step() API → time-travel debug + DAP) ``` --- ### Açık Sorular - Bu sıralama "zorunlu" değil — örn. modül sistemi (#81-83) erken talep edilirse Aşama C öne çekilebilir. Amaç, "hangi iş hangi mimari yatırımı **gereksiz yere tekrarlatır**" sorusuna karşı bir kontrol listesi olmak. - Aşama B'deki "gömülebilir derleyici" kararı, Faz 2-3 sınıflarının (SymbolTable, DiagnosticEngine) **API tasarımına** şimdiden not düşülmeli mi (örn. "bu sınıf bir kere oluşturulup birden çok `analyze()` çağrısı arasında state tutabilmeli")? Bu, geriye dönük en maliyetli değişikliklerden biri olur. *İmza/Yorum:* Bu issue bir "yapılacak iş" değil, bir **harita** — #91, #93-98, #107 arasındaki gizli bağımlılıkları görünür kılmak için. Her aşama tamamlandığında bu harita güncellenmeli.

saqut added the

fikir

gelecek-vizyon

cli-ux

labels 2026-06-14 22:38:39 +03:00

Sign in to join this conversation.