[Fikir] Builtin Fonksiyon Kataloğu ve Çözümleme Mekanizması #89

New Issue

saqut · 2026-06-14T22:14:04+03:00

saqut commented

2026-06-14 22:14:04 +03:00

Giriş (Nedir, Neden Önemli?)

print ilk builtin (yerleşik) fonksiyon. Ama "builtin" kelimesinin derleyici içinde nasıl bir yeri olacağı — sembol tablosunda mı, ayrı bir kayıt defterinde mi — henüz netleşmedi. Bu issue, print'ten sonra gelecek len, toString, parseInt gibi fonksiyonların sistematik bir şekilde eklenmesini planlar.

Gelişme (Olası Yaklaşımlar)

Faz 2'nin Symbol Table'ı (sembol tablosu) başlangıçta "önceden tanımlı" (pre-defined) bir global scope ile kurulabilir — her builtin, kullanıcı kodu hiç okunmadan önce bu scope'a SymbolKind::Function olarak eklenir. Böylece print(x) çağrısı normal bir fonksiyon çağrısı gibi tip denetiminden (Faz 3) geçer.
Builtin kataloğu merkezi bir dosyada (src/runtime/builtins.hpp gibi) tek listede tutulur: isim, parametre tipleri, dönüş tipi, ve VM'deki karşılığı (FFI üzerinden mi, yoksa doğrudan bir IR opcode'u mu).
İlk aday liste (fibonacci sonrası "küçük kazanımlar"): print, len (string/array uzunluğu), toString (sayıdan string'e), parseInt/parseFloat.

Açık Sorular

Builtin'ler kullanıcı tarafından gölgelenebilir (shadow) mi — yani kullanıcı kendi print fonksiyonunu tanımlarsa ne olur (muhtemelen E002 çift tanım, ama global scope'ta builtin'lerle çakışma ayrı ele alınmalı)?
Builtin kataloğu büyüdükçe (örn. 50+ fonksiyon), bunların hepsi "her zaman yüklü" mü olacak, yoksa modül sistemi (ayrı issue) ile "import edilen" bir stdlib mantığına mı evrilecek?

İmza/Yorum: print'in nasıl çözümlendiğini doğru kurmak, sonraki tüm builtin'lerin şablonu olacak — bu yüzden bu issue erken (Faz 2-3 sırasında) gündeme gelmeli.

### Giriş (Nedir, Neden Önemli?) `print` ilk builtin (yerleşik) fonksiyon. Ama "builtin" kelimesinin derleyici içinde nasıl bir yeri olacağı — sembol tablosunda mı, ayrı bir kayıt defterinde mi — henüz netleşmedi. Bu issue, `print`'ten sonra gelecek `len`, `toString`, `parseInt` gibi fonksiyonların **sistematik** bir şekilde eklenmesini planlar. --- ### Gelişme (Olası Yaklaşımlar) - Faz 2'nin Symbol Table'ı (sembol tablosu) başlangıçta "önceden tanımlı" (pre-defined) bir global scope ile kurulabilir — her builtin, kullanıcı kodu hiç okunmadan önce bu scope'a `SymbolKind::Function` olarak eklenir. Böylece `print(x)` çağrısı normal bir fonksiyon çağrısı gibi tip denetiminden (Faz 3) geçer. - Builtin kataloğu merkezi bir dosyada (`src/runtime/builtins.hpp` gibi) tek listede tutulur: isim, parametre tipleri, dönüş tipi, ve VM'deki karşılığı (FFI üzerinden mi, yoksa doğrudan bir IR opcode'u mu). - İlk aday liste (fibonacci sonrası "küçük kazanımlar"): `print`, `len` (string/array uzunluğu), `toString` (sayıdan string'e), `parseInt`/`parseFloat`. --- ### Açık Sorular - Builtin'ler kullanıcı tarafından **gölgelenebilir (shadow)** mi — yani kullanıcı kendi `print` fonksiyonunu tanımlarsa ne olur (muhtemelen `E002` çift tanım, ama global scope'ta builtin'lerle çakışma ayrı ele alınmalı)? - Builtin kataloğu büyüdükçe (örn. 50+ fonksiyon), bunların hepsi "her zaman yüklü" mü olacak, yoksa modül sistemi (ayrı issue) ile "import edilen" bir stdlib mantığına mı evrilecek? *İmza/Yorum:* `print`'in nasıl çözümlendiğini doğru kurmak, sonraki tüm builtin'lerin şablonu olacak — bu yüzden bu issue erken (Faz 2-3 sırasında) gündeme gelmeli.

saqut added the

fikir

ffi-builtin

labels 2026-06-14 22:14:04 +03:00

saqut referenced this issue

2026-06-14 22:26:27 +03:00

[Test] Builtin Fonksiyonların Kullanım Örnekleri (`print`, `len`, `toString`, `parseInt`, ...) #102

saqut referenced this issue

2026-06-14 22:37:46 +03:00

[Fikir] LSP Sunucusu — Derleyici Tamamlandığında Tam Yetenek Haritası (Tier 1-4) #91

saqut referenced this issue

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