Concepts of Programming Languages Sıfırdan Çalışma Rehberi

Dersin Künyesi

Hocanın ilk derste anlattığı organizasyon bilgileri — ne, ne zaman, kaç puan. (⭐ = hocanın vurguladığı, sınavda çıkması muhtemel konu; ⭐⭐ = en güçlü adaylar.)

Bu ders tek bir dili öğretmez; dillerin kendisini inceler. Amaç, önüne bir problem geldiğinde "bunu hangi dille, hangi yaklaşımla çözmek en mantıklı?" sorusuna cevap verebilmen. Hoca ilk derste bunu defalarca tekrarladı: herkes bildiği dille yazmaya çalışıyor, ama doğru araç çoğu zaman başka bir paradigm oluyor.

• Önkoşul: SE 116 (Introduction to Programming II) — hoca OOP bildiğinizi varsayıyor.
• Devam zorunlu: dersler kaydediliyor ama hoca açıkça söyledi: "There is no watching later" — kayıttan izlemek devam yerine geçmiyor.
• Lab yok: kod örnekleri dersin içinde çözülüyor; aynı problem farklı dillerde tekrar tekrar yazılıyor.
• Gerçekleşen konu akışı: Ch.1–2 (giriş + tarih) → Ch.3–4 (syntax/semantics + parsing) → Ch.5 (names/bindings/scopes) → Ch.6 (data types) → Ch.7–8 (expressions/assignment) → vize → Ch.9 (subprograms) → Ch.10 (implementing subprograms) → Ch.11 (ADT) → Ch.12 (OOP desteği — 10 Ağustos, son ders). İlk derste planlanan Ch.14 (exception/event handling) işlenmedi — dönem 10 Ağustos'ta Ch.12 ile kapandı, hoca o oturumda açıkça "this is the last session… we now finally closed this course" dedi. Dolayısıyla Ch.14 final kapsamı dışıdır.

Vize Sınav Radarı

Hocanın kendi ağzından, sınav hakkında söylediği her şey tek yerde.

Bu rehberdeki fosforlu kutular hocanın derste üzerinde durduğu, tekrarladığı veya "bunu bilmelisiniz" dediği yerler; konu anlatımındaki ⭐ işaretli başlıklar da sınavda çıkması en muhtemel konuları gösterir. Sınava az vaktin varsa önce yıldızlı başlıkları, fosforlu kutuları ve Deneme Sınavı + Soru Havuzu bölümlerini çalış.

1 · Giriş & Motivasyon

Sebesta Ch.1 — 6 Temmuz oturumunun tamamı. Hoca bu bölümü "dersin neden var olduğunun cevabı" olarak anlattı.

⭐⭐ Bu dersi neden okuyorsun?

Hocanın ilk derste en çok zaman ayırdığı soru buydu. Cevabın özü bir dil felsefesi gözlemine dayanıyor: düşünebildiğin şey, anlatabildiğin şeyle sınırlı. Hoca bunu şöyle aktardı: "the depth at which people can think is influenced by the expressive power of the language" — yani bildiğin diller/yapılar arttıkça, kurabildiğin çözümler de artıyor. Türkçe gramerini bilen birinin ikinci bir dili çok daha kolay öğrenmesi gibi: buradaki kavramları öğrenince yeni bir programlama dili öğrenmek günler meselesine iniyor.

Sebesta'nın (ve hocanın tek tek üzerinden geçtiği) 6 gerekçesi:

1. Fikirleri ifade etme gücü artar — daha çok yapı bilirsen daha çok çözüm düşünebilirsin.
2. Doğru dili seçebilirsin — probleme göre dil/paradigma seçimi bu dersin ana hedefi.
3. Yeni dilleri kolay öğrenirsin — kavramlar ortak; sözdizimi detay.
4. Implementation'ın önemini anlarsın — dilin arka planda nasıl çalıştığını bilmek, verimli kod yazdırır ve hataları anlamayı kolaylaştırır.
5. Bildiğin dilleri daha iyi kullanırsın — dilinin az bilinen köşelerini keşfedersin.
6. Bilişimin genel ilerlemesine katkı — popüler dilin her zaman en iyi dil olmadığını görebilen bir nesil.

⭐ Programlama alanları (programming domains)

Farklı problem alanları, farklı ihtiyaçlar doğurur; farklı diller de tam olarak bu yüzden var. Hoca her alanı "neye ihtiyaç duyar → hangi dil" kalıbıyla anlattı; bu eşlemeyi ezbere bilmen gerekiyor:

⭐ Bir dili nasıl değerlendiririz?

Sebesta'nın meşhur dört kriteri. Hoca 1970'i dönüm noktası olarak anlattı: öncesinde tek dert "çalışan kod"du; sonrasında yazılımın bakımı pahalılaşınca kodun okunabilirliği kalite ölçütü oldu.

1 · Readability (okunabilirlik)

Programın okunup anlaşılma kolaylığı. Dört faktörü var:

• Overall simplicity: dilin yönetilebilir sayıda yapısı olmalı. Üç düşmanı var: (a) feature subset — dil o kadar büyük ki herkes farklı bir alt kümesini öğreniyor; (b) feature multiplicity — aynı işin birden çok yolu. Hocanın örneği Java'da sayıyı artırmanın dört yolu: count=count+1, cnt+=1, cnt++, ++cnt (bu örneği kendisi verdi ve "that's why I don't like Java so much" diye espri yaptı); (c) operator overloading'in aşırı kullanımı.
• Orthogonality: az sayıda temel yapı + az sayıda birleştirme kuralı, ve her kombinasyon geçerli. Ne kadar ortogonal, o kadar az istisna; az istisna = kolay öğrenme. Hocanın karşı örneği İngilizce imla kuralları: istisna üstüne istisna.
• Data types: yeterli hazır veri tipi olmalı (ör. boolean yoksa int'le bayrak tutmak okunabilirliği düşürür).
• Syntax considerations: anlamlı keyword'ler, esnek tanımlayıcı isimleri, kendini anlatan yapılar. Hocanın kötü tasarım örneği C'deki static: fonksiyon içinde "compile time'da yarat" demek, dosya düzeyinde "sadece bu dosyadan görünsün" demek — aynı kelime iki farklı anlam, okunabilirlik zehri.

2 · Writability (yazılabilirlik)

• Simplicity + orthogonality burada da geçerli — ama hocanın uyarısı: aşırı ortogonallik de tehlikeli; neredeyse her kombinasyon geçerliyse, hatalar derleyiciye takılmadan geçer.
• Expressivity: işlemleri ifade etmenin pratik yolları (zengin operatörler, hazır fonksiyonlar).
• Abstraction: karmaşık yapıları detaylarını görmeden tanımlayıp kullanabilmek.

3 · Reliability (güvenilirlik)

• Type checking: tip hatalarını yakalamak.
• Exception handling: çalışma zamanı hatasını yakalayıp toparlanabilmek.
• Aliasing: aynı bellek konumuna iki farklı isimle erişim — kısıtlı olması güvenilirliği artırır.
• Readability ve writability da güvenilirliği besler: algoritmayı "doğal" ifade edemediğin dilde dolambaçlı çözümler yazarsın, dolambaçlı kod daha çok hata barındırır.

4 · Cost (maliyet)

Eğitim + kod yazma + derleme + çalıştırma + derleyici/araç maliyeti + düşük güvenilirliğin faturası + bakım. Hoca bakım maliyetinin çoğu zaman geliştirme maliyetini aştığını vurguladı. Bonus kriterler: portability (başka ortama taşınabilirlik), generality (geniş uygulama alanı), well-definedness (resmi tanımın eksiksizliği).

⭐ von Neumann mimarisi — dillerin şekillendiği kalıp

Hoca burada resmen mini bir mimari dersi yaptı; gerekçesi de netti: "you don't have any architecture courses. So we will make a crash course." Çünkü bugünün baskın dil ailesi (imperative), doğrudan bu mimarinin ürünü.

von Neumann architecture'ın özü iki cümle: veri ve program aynı bellekte durur; bellek CPU'dan ayrıdır ve komutlar/veri ikisi arasında "borularla" (pipe) taşınır. Dillerle bağlantısı birebir:

• Variable = bellek hücresinin soyutlaması,
• Assignment (atama) = bellek–CPU arası taşımanın (piping) soyutlaması,
• Iteration (döngü) = komutların bellekte yan yana durmasından dolayı verimli.

CPU'nun ritmi fetch-execute cycle: program counter'ın gösterdiği komutu bellekten getir → sayacı artır → komutu çöz (decode) → çalıştır → sonsuza kadar tekrarla. Getirilen komut instruction register'a yüklenir; aritmetik ALU'da yapılır (hocanın benzetmesiyle ALU "katır" gibi işi yapan, control unit ise "beyin").

Bir de darboğaz var: komutların işlenme hızı, bellek–CPU bağlantısının hızından çok daha yüksek. Bu bağlantı hızı bilgisayarın hızını sınırlar; buna von Neumann bottleneck denir. Hoca sayı da verdi: 7200 rpm bir disk ile modern bir i5/i7 arasında tek veri erişiminde "15–20 milyon cycle" boşa gidebilir.

⭐ Metodolojilerin etkisi — kısa tarih

Dil tasarımını mimari kadar, yazılım geliştirme alışkanlıkları da şekillendirdi. Kronoloji sınav dostu:

• 1950'ler–60 başı: donanım pahalı → tek dert machine efficiency.
• 60'ların sonu: maliyet donanımdan yazılıma kaydı → people efficiency, readability, structured programming, top-down design, stepwise refinement.
• 70'lerin sonu: süreç odaklıdan veri odaklıya → data abstraction (ADT).
• 80'lerin ortası: OOP doğdu. Hocanın tahtaya yazdığı formül: OOP = data abstraction + inheritance + polymorphism.

⭐ Dil kategorileri

⭐ Tasarım ödünleşimleri (trade-offs)

Her kriter aynı anda maksimize edilemez; üç ezber örnek:

• Reliability ↔ cost of execution: Java her dizi erişiminde sınır kontrolü yapar → güvenli ama yavaş.
• Readability ↔ writability: APL — bir satırda müthiş işler, ama "traded readability for writability"; yazması hızlı, okuması işkence.
• Writability/flexibility ↔ reliability: C++ pointer'ları — güçlü ve esnek, ama güvenilmez. Hocanın tabiriyle "pointers in C are a nightmare for all students."

⭐ Implementation: dil nasıl hayata geçer?

Yazdığın kaynak kod üç yoldan biriyle makineye ulaşır.

1 · Compilation

Program bir bütün olarak makine diline çevrilir: çeviri yavaş, çalıştırma çok hızlı. Fazlar:

1. Lexical analysis: karakter dizisini lexeme'lere ayırır (identifier'lar, keyword'ler, operatörler, noktalama).
2. Syntax analysis: lexeme'lerden programın hiyerarşik yapısını gösteren parse tree'leri kurar.
3. Semantic analysis: ara kod üretir; syntax'ın yakalayamadığı anlam hatalarını bulur. Hocanın örneği: eksik noktalı virgülü syntax analyzer görür ama iç içe if'lerdeki uyumsuz dallanmayı semantic analyzer yakalar.
4. Code generation: makine kodu üretilir.

Süreç boyunca symbol table kullanılır — hocanın tanımıyla "a database for the compilation process". Sonra linking ile sistem kütüphaneleri eklenir; ortaya çıkan bütüne load module (executable image) denir.

2 · Pure interpretation

Hiç çeviri yok; bir interpreter kodu doğrudan yürütür — "software simulation of a machine". Hata ayıklama kolay (hata anında, satırıyla görünür) ama çalıştırma 10–100 kat yavaş. Web scripting dilleriyle (JavaScript, PHP) geri dönüş yaptı.

3 · Hybrid + JIT

Orta yol: kaynak kod önce bir ara dile çevrilir, ara dil yorumlanır. Java'nın klasik hikâyesi: kod → byte code → JVM her platformda çalıştırır → taşınabilirlik. JIT ise bunun hızlandırılmışı: ara dildeki alt programlar çağrıldıkları anda makine koduna derlenir ve sonraki çağrılar için saklanır. Hocanın tek cümlelik tanımı: "JIT systems are essentially delayed compilers." .NET dilleri de böyle çalışır.

Bir de preprocessor var: derlemeden hemen önce çalışan "macro expander" — C'deki #include, #define satırlarını genişletir.

2 · Büyük Dillerin Evrimi

Sebesta Ch.2 — 7 Temmuz oturumunun tamamı. Bölüm baştan sona bitirildi; ders "aynı problemin 12 dilde çözümü" örnekleriyle kapandı.

⭐ Ana tema: her dil, ortamının ürünüdür

Hoca bu üç saatlik dersi tek bir fikrin etrafında anlattı: hiçbir dil boşlukta doğmaz. Her dili tanıtırken önce "environment of development"i kurdu, sonra tasarım kararlarını o ortamla açıkladı. Kapanışta öğrenme hedefini de aynen böyle tarif etti: "you should be able to know the development environments and evolution of important programming languages."

Kronoloji — kim, neden, ne getirdi?

Tarih öncesi: Plankalkül ve pseudocode'lar

İlk programlama dili bir Alman mühendisten: Konrad Zuse (hocanın deyişiyle "the father of computer" — savaş yıllarında binary çalışan makineler yaptı, Z4'le Bavyera'ya kaçtı, tarih onu uzun süre görmezden geldi). Plankalkül 1945'te tasarlandı ama 1972'ye kadar yayımlanmadı ve hiç implement edilmedi. Buna rağmen çağının ötesindeydi: floating point, arrays ve records (hiyerarşik veri) içeren ilk dildi.

Makine kodunun dertleri (okunmaz, değiştirilmez, ifade yazmak işkence, donanımda indexing/floating point yok) pseudocode'ları doğurdu — "koda benzeyen ama gerçek kod olmayan" ara diller:

• Short Code (Mauchly, 1949, BINAC/UNIVAC I): ifadeler soldan sağa kodlanıyor; saf yorumlamayla çalışıyordu ve makine kodundan ~50 kat yavaştı — o dönem buna "automatic programming" deniyordu.
• Speedcoding (Backus, IBM 701): aritmetik/matematik pseudo-op'ları, otomatik artan register'lar; ama yavaş ve kullanıcı programına yalnızca 700 kelime bellek kalıyordu. Backus'un iddiası: makine kodunda iki haftalık iş, speedcoding'le birkaç saat.
• Grace Hopper'ın ekibi pseudocode'u makine koduna genişleten "compiling system"i geliştirdi; Wheeler relocatable address bloklarıyla mutlak adresleme derdini çözdü.

⭐ Fortran (1957): her şeyi değiştiren dil

IBM 704, floating point'i donanımda yapan ilk makineydi. O güne kadar yorumlamanın maliyeti, zaten yazılımla yapılan floating point'in gölgesinde kalıyordu; donanım gelince bahane bitti — "there was no place to hide the cost of interpretation" — ve derlenen dil fikri doğdu. Hoca iki kez tekrarladı: "one single computer can change everything"; IBM 704 + Fortran olmasaydı bugün burada olmazdık.

Sürüm zinciri (sınavda "hangi sürüm neyi getirdi?" eşleştirmesi olarak düşün):

⭐ Lisp (1959): fonksiyonel devrim

MIT'de McCarthy'nin ("artificial intelligence" teriminin de babası) AI araştırması için tasarladığı LISt Processing dili. Fortran'da recursion ve conditional expression yoktu; AI'ın ihtiyacı olan sembolik hesap için yeni dil şarttı. Yapısı radikal derecede basit: yalnızca iki veri tipi — atoms ve lists; sözdizimi lambda calculus temelli.

• Scheme (MIT, 1970'lerin ortası): küçük, static scoping, fonksiyonlar first-class; eğitim için ideal. Hocanın itirafı: giriş dersini kendisi verse Scheme kullanırdı.
• Common Lisp: bütün lehçeleri birleştirme çabası → büyük ve karmaşık. Hocanın benzetmesi: Esperanto gibi — "the outcome was a mess."
• ML: fonksiyonel ama tipler compile time'da; type inference (bağlamdan tip çıkarımı) kullanır.

⭐ ALGOL 60: hiç yaygınlaşmadan her şeyi etkileyen dil

Hocanın bu derste en ağır vurguladığı dil. Sorun şuydu: her dil tek makineye bağlıydı, algoritma paylaşmak için evrensel, makineden bağımsız bir dil yoktu. ACM ve GAMM 1958'de masaya oturdu; hedefler: matematiksel notasyona yakınlık, algoritma tarifine uygunluk, makine koduna çevrilebilirlik. ALGOL 58 taslağının ardından 1960 Paris toplantısında ALGOL 60 doğdu. Getirdikleri:

• Block structure — yerel scope kavramı,
• İki parametre geçirme yöntemi: pass by value ve pass by name,
• Imperative dillerde ilk recursion (Lisp'te 1959'da vardı ama imperative dünyada yoktu),
• Stack-dynamic arrays — boyutu değişkenle belirlenen, bildirime gelindiğinde bellek ayrılan diziler.

⭐ COBOL (1959–60): iş dünyasının İngilizcesi

Grace Hopper'ın FLOW-MATIC'inden doğdu; temel fikir: "data processing programs should be written in English." Pentagon'daki tasarım toplantısının hedefleri bugün bile ders niteliğinde: basit İngilizce gibi görünmeli; daha az güçlü olmak pahasına kolay olmalı; bilgisayar kullanıcı tabanını genişletmeli. (Hocanın anekdotu: komitede yalnızca üretici firmalar ve DoD vardı, iş dünyasından kimse yoktu; toplantı da "bilimsel toplantıdan çok kavgaya" dönmüştü.)

• Katkılar: ilk macro facility; hiyerarşik veri yapılarının (records) ilk implementasyonu (dikkat — hoca özellikle düzeltti: kavramı ilk tanıtan Plankalkül'dü, COBOL ilk hayata geçiren); nested selection; 30 karaktere kadar tireli isimler; data division.
• DoD'nin zorunlu kıldığı ilk dil — hocaya göre DoD olmasaydı batardı; ama hâlâ en yaygın iş uygulaması dili. Güncel not: "IBM Europe is still looking for people who know COBOL."

⭐ BASIC (1964): kullanıcı zamanı devrimi

Kemeny & Kurtz, Dartmouth. Hedef kitle fen öğrencisi bile değil: dil "pleasant and friendly" olacak, ödev hızlı dönecek, erişim ücretsiz ve özel olacak. Asıl devrim şu cümlede: "user time is more important than computer time" — hocaya göre "that was very revolutionary", çünkü o güne dek makine insan emeğinden değerliydi. Timesharing'i geniş kullanıma sokan ilk dil. İlk sürümü mini bir dildi: 14 statement tipi, tek veri tipi (floating point). Güncel torunu: Visual Basic.

⭐ PL/I (1965): herkese her şey

1963'e gelindiğinde IBM'in iki ayrı dünyası (bilimsel: 7090+Fortran+SHARE; iş: 1401+COBOL+GUIDE) birbirinin özelliklerini istemeye başladı. İki tür makine + iki dil + iki destek ekibi çok pahalıydı; "çözüm": her iki işi de yapan tek makine (System/360) ve tek dil. PL/I, 3×3 komiteyle (3 IBM + 3 SHARE) beş ayda tasarlandı — "the first large-scale attempt to design a language for a broad spectrum of application areas."

• Aldıkları: ALGOL 60'tan recursion + block structure; Fortran IV'ten separate compilation; COBOL'dan data structures + I/O.
• İlk'leri: unit-level concurrency, exception handling, switch-selectable recursion, pointer data type, array cross-sections.
• Sorunu: çok büyük, çok karmaşık, birçok özellik kötü tasarlanmış — özellikle pointer. Hocanın anısı: "I can remember from my student times that it is a torture."

⭐ APL & SNOBOL: erken dinamik diller

İkisinin ortak önemi kategorik: dynamic typing + dynamic storage allocation kavramlarını tanıttılar. Değişkenler tipizdir; tip de bellek de değer atandığı anda gelir (a=1 → integer, a=1.0 → real). APL (Ken Iverson, IBM): aslında donanım tarifi için tasarlandı; operatör zenginliği yüzünden "programs are very difficult to read". SNOBOL (Bell Labs): string pattern matching'in gücü, ama yavaş.

⭐ SIMULA 67: OOP'nin tohumu

Norveç'te Nygaard & Dahl, sistem simülasyonu için. İki tarihi katkı: coroutine — hocanın tanımıyla çağıran ve çağrılanın "somewhat equal relation" kurduğu alt program (o güne dek ilişki "master-slave" idi) — ve class, object, inheritance kavramları. Hocanın cümlesi: "data abstraction started with Simula 67" — OOP'ye giden yolu bu dil açtı.

⭐ ALGOL 68: orthogonality'nin dili

Lecture 1'deki orthogonality kavramına iki kez geri bağlandı ("remember yesterday"): orthogonality ilkesi üzerine kurulan ilk dil — az sayıda temel kavram + az sayıda birleştirme mekanizması. Sonuçları: user-defined data types (temel tipleri serbestçe birleştirebilmenin doğal ürünü), reference types, ve dynamic (flex) arrays — bildirimde boyut yok, atama geldiğinde bellek otomatik ayrılıyor. Kendisi tutmadı ama Pascal, C ve Ada'yı derinden etkiledi.

⭐ ALGOL'un torunları: Pascal, C ve Prolog dönemi

• Pascal (1971): Wirth (ALGOL 68 komitesinden ayrılan üye). Yeni hiçbir şey yok — küçük, basit, structured programming öğretimi için. 70'lerin ortasından 90'ların sonuna kadar programlama öğretiminin dili (hocanın kuşak anısı: "bizim gençliğimizde hangi mühendisliği okursan oku Pascal'la başlardın").
• C (1972): Ritchie, Bell Labs, sistem programlama için. Soy zinciri sınavlık: CPL → BCPL → B → C (+ ALGOL 68'den for/switch ve atama operatörleri). Karakteri tek cümle: "powerful set of operators, but poor type checking." UNIX'le yayıldı.
• Prolog (1972): Colmerauer & Roussel (Aix-Marseille) + Kowalski (Edinburgh). Formal logic tabanlı, non-procedural. Hocanın "how vs what" karşıtlığı: imperative dilde nasıl hesaplanacağını yazarsın; Prolog'da ne istediğini bildirirsin, çıkarımı motor yapar. Tanımı: "an intelligent database system that uses an inferencing process." Verimsizliği yüzünden dar alanda kaldı — ama hoca güncel bağ kurdu: "prompting is mostly based on logic" (LLM çağında logic yeniden değerli).

⭐ Ada: tarihin en büyük tasarım çabası

DoD'nin problemi: gömülü sistemlerde 450'den fazla farklı dil kullanılıyordu. Çözüm: tek ortak dil. Yüzlerce kişi, ~8 yıl, dev bütçe; gereksinim dokümanları sınavlık bir dizi: Strawman → Woodman → Tinman → Ironman → Steelman (1975–78). İsim, tarihin ilk programcısı Augusta Ada Byron'dan. Katkılar: packages (data abstraction), ayrıntılı exception handling, generics, tasking modeliyle concurrency. Ders niteliğindeki dipnot: kullanılabilir ilk derleyici, tasarımdan beş yıl sonra geldi — "not good for language design." Ada 95 OOP'yi type derivation ile ekledi; DoD zorunluluğu kalkınca ve C++ yükselince popülerliği düştü.

⭐ OOP çağı: Smalltalk → C++ → Java

• Smalltalk: Alan Kay'in (Xerox PARC) öngörüsünün ürünü; ilk TAM object-oriented dil — data abstraction + inheritance + dynamic binding. GUI tasarımının da öncüsü.
• C++ (1980): Stroustrup, Bell Labs. Formül: C'nin imperative gücü + SIMULA 67'nin OO özellikleri. Hem prosedürel hem OO desteklediği için büyük ve karmaşık; OOP dalgasıyla hızla yayıldı; ANSI standardı 1997. (Akrabalar: Objective-C/Swift — Apple; Delphi — Hejlsberg'in nesne yönelimli Pascal'ı.)
• Java (1990'ların başı, Sun): gömülü elektronik için C++ yetersizdi (güvenilmezdi). Java = C++'ın "smaller, simpler, safer" hali: struct/union/enum yok, pointer arithmetic yok, coercion'ların yarısı yok; pointer yerine reference; yalnızca OOP. Taşınabilirliği JVM + JIT sağlar. (Hocanın anekdotu: Sun'ın Java'lı tüketici cihazları hiç satılmadı — dili kurtaran web oldu.)

Scripting dilleri ve .NET

Markup/programlama melezleri: XSLT (XML'i görüntülemek için dönüştürür; döngü yapıları var — "dil midir?" tartışması) ve JSP/JSTL (HTML elemanı biçiminde programlama yapıları).

⭐⭐ "İlk"ler tablosu — bu bölümün altın özeti

Hocanın anlatımında her dilin etiketi bir "ilk"ti. Quiz ve vizenin en olası eşleştirme sorusu:

⭐ Karşıtlıklar — hocanın sevdiği kıyaslar

• Java ↔ JavaScript: isim benzerliği aldatmaca; strongly typed ↔ dynamically typed.
• Client-side ↔ server-side: JavaScript tarayıcıda, PHP sunucuda çalışır.
• How ↔ what: imperative "nasıl"ı, logic programming "ne"yi tarif eder.
• Scheme ↔ Common Lisp: küçük/temiz/eğitimlik ↔ büyük/karmaşık/endüstriyel ("Esperanto gibi, sonuç karman çorman").
• Pass by value ↔ pass by name: ikisi de ALGOL 60'ta doğdu.

3 · Syntax, Semantics & Parsing

13 Temmuz oturumunun tamamı — dersin en teknik ve sınava en yakın bölümü. (Not: Ch.3'ün ikinci yarısı — attribute grammars ve semantik tanımlama yöntemleri — bu derste işlenmedi.)

⭐ Syntax ve semantics: biçim ile anlam

Hoca dersin ilk 40 dakikasını bu iki tanıma ayırdı — quiz için birincil aday:

• Syntax: ifadelerin, deyimlerin ve program birimlerinin biçimi/yapısı.
• Semantics: aynı şeylerin anlamı.

"Ahmet" analojisiyle anlattı: gözün harf dizisini görmesi ve kelimeyi tanıması syntax; beynin "bu bir erkek ismidir" demesi semantics. İki kilit cümlesi: "In a well-designed programming language, semantics should follow directly from the syntax" (if A > B yazımı, anlamını sezdirmeli) ve "describing syntax is easier than describing the semantics" — çünkü syntax için evrensel kabul görmüş bir notasyon (BNF) var, semantics için hâlâ yok. Dil tanımını üç kitle okur: diğer dil tasarımcıları, implementer'lar ve programcılar.

Terminoloji zinciri (hoca iki kez anlattı — iki kez anlatılan her şey gibi sınav adayı):

Bir dili formal tanımlamanın iki yolu: recognizer (girdi dizisinin dile ait olup olmadığına karar veren cihaz — derleyicinin syntax kontrolü böyledir) ve generator (dilin cümlelerini üreten cihaz — hocanın metaforuyla "her düğmeye bastığında bir cümle üreten makine"). İnsanlar tarif olarak generator'ı tercih eder; recognizer'ı tarif olarak kullanmak deneme-yanılma gerektirir.

⭐ BNF: kuralların anatomisi

Bir BNF kuralı (rule ya da production) iki yandan oluşur: LHS (sol taraf) her zaman tek bir nonterminal; RHS (sağ taraf) terminal ve/veya nonterminal dizisi. Alternatifler | (VEYA) ile ayrılır. Grammar = sonlu, boş olmayan kural kümesi + özel bir start symbol. LHS'i kendi RHS'inde yeniden gören kurala recursive rule denir — listeler böyle tarif edilir:

<ident_list> → ident
              | ident , <ident_list>

Hocanın kendi kedisinden ilhamla yazdığı İngilizce grammar örneği ("the tall man ate the cat") derste adım adım türetildi — aynı grammar "tall cat ate the man" gibi cümleleri de üretir; grammar neyi üretebiliyorsa dil odur.

⭐⭐ Türetim (derivation) ve parse tree

Derivation: start symbol'den başlayıp kuralları tekrar tekrar uygulayarak, yalnızca terminal içeren bir cümleye ulaşmak. Aradaki her dizi bir sentential form; sadece terminal kalan son hâli sentence. => "derives" diye okunur. Her adımda en soldaki nonterminal açılıyorsa leftmost derivation, en sağdaki açılıyorsa rightmost — ve önemli sonuç: türetim sırası dili değiştirmez.

<program> → <stmts>
<stmts>   → <stmt> | <stmt> ; <stmts>
<stmt>    → <var> = <expr>
<var>     → a | b | c | d
<expr>    → <term> + <term> | <term> - <term>
<term>    → <var> | const

<program> => <stmts> => <stmt>
          => <var> = <expr>
          => a = <expr>
          => a = <term> + <term>
          => a = <var> + <term>
          => a = b + <term>
          => a = b + const  (0)   ✓ geçerli

Parse tree, türetimin hiyerarşik (ağaç) gösterimi: kök start symbol, iç düğümler nonterminal'ler, yapraklar terminal'ler. Unambiguous bir grammar'da her türetimin parse tree'si tektir — leftmost da yapsan rightmost da yapsan aynı ağaç çıkar.

⭐ Ambiguity: bir cümle, iki ağaç

Bir grammar, aynı cümle için iki veya daha fazla farklı parse tree üretebiliyorsa ambiguous'tur. Neden ciddi bir problem? Hocanın iki kez tekrarladığı cümle: "compiler generates code based on the parse tree — two different parse trees means the code cannot be unique." Yani aynı program iki farklı anlama derlenebilir.

Derste çözülen örnek: <expr> → <expr> <op> <expr> | const, <op> → / | - grammar'ında const - const / const iki ağaç verir (önce çıkarma mı, önce bölme mi?). Çözüm: öncelik seviyelerini grammar'ın katmanlarına gömmek:

<expr> → <expr> - <term> | <term>
<term> → <term> / const | const

Böylece / her zaman ağacın daha altında kalır ve kural şudur: ağaçta daha aşağıda olan operatör önce hesaplanır = önceliği daha yüksektir. Aynı öncelikte iki operatör varsa devreye associativity girer (soldan mı sağdan mı gruplama — bunu da grammar'daki recursion'ın yönü belirler).

⭐ EBNF: üç kolaylık

Bu ayraçlar meta symbol'dür — notasyon aracı, terminal değil. BNF'teki sol-recursive <expr> → <expr> + <term> | ... kuralları EBNF'te <expr> → <term> {(+|-) <term>} biçimine sadeleşir.

⭐ Part 2 — Lexical analysis: karakterden token'a

Lexical analyzer, hocanın tanımıyla "essentially a pattern matcher for character strings" ve parser'ın front end'i. Teknik olarak syntax analysis'in parçasıdır ama ayrı tutulur; parser'ın ihtiyaç duydukça çağırdığı bir fonksiyondur ("give me the next token"). Yan görevleri: boşluk ve yorumları atlamak, isimleri symbol table'a koymak, token içi hataları (bozuk sayı sabiti gibi) raporlamak.

Matematiksel temel: lexer bir finite automaton'dur ve regular language'ları tanır; tasarımı state diagram (yönlü graf: düğümler durum, oklar girdi karakteri) ile yapılır. Naif diyagram devasa olur; iki akıllı sadeleştirme:

• Character class: 52 harfi tek "letter", 10 rakamı tek "digit" sınıfına indir — identifier tanırken hangi harf olduğunun önemi yok.
• Reserved word'lere ayrı diyagram yok: hepsini identifier gibi tanı, sonra table lookup ile "bu aslında reserved word mü?" diye bak. Her keyword için ayrı dal çizmek "not very intelligent."

Sebesta'nın front.c lexer'ının üç yardımcı alt programı (isimleriyle sınavlık): getChar (sonraki karakteri al, sınıfını belirle), addChar (karakteri kurulan lexeme'e ekle), lookup (lexeme reserved word mü?). Hoca (sum + 47) / total girdisinin token döküm çıktısını satır satır okudu ve kodun s.166–170'te olduğunu, çalıştığını söyledi ("I tested the code. It works."). İnce ayrım: symbol table'a isimleri lexer koyar; attribute'ları derleyicinin sonraki fazları doldurur.

⭐ Parsing: ağacı yukarıdan mı, aşağıdan mı kurarsın?

Parser'ın iki hedefi: (1) tüm syntax hatalarını bulmak, anlamlı mesaj vermek ve recovery yapmak (toparlanıp devam etmek ki tek derlemede olabildiğince çok hata bulunsun), (2) parse tree'yi (ya da izini) üretmek — çeviri bu ağaç üzerinden yapılır.

Hocanın ezber formülü: "root–leftmost, leaves–rightmost. Top-down, bottom-up." Pratik parser'lar girdide yalnızca bir token ileriye bakar (lookahead). Açılımlar da ezber: LL = Left-to-right scan + Leftmost derivation; LR = Left-to-right scan + Rightmost derivation. Karmaşıklık: rastgele bir unambiguous grammar'ı parse etmek O(n³); derleyiciler grammar'ların uygun bir alt kümesiyle O(n)'de çalışır.

⭐ Recursive-descent parsing

Fikir zarif: grammar'daki her nonterminal için bir alt program yaz; nonterminal'in üretebileceği cümleleri o alt program parse etsin. EBNF bu iş için biçilmiş kaftan çünkü nonterminal sayısını azaltır. Derste şu grammar'ın C kodu satır satır izlendi:

<expr>   → <term> {(+ | -) <term>}
<term>   → <factor> {(* | /) <factor>}
<factor> → id | int_constant | ( <expr> )

void expr() {
  term();                                /* ilk term */
  while (nextToken == ADD_OP || nextToken == SUB_OP) {
    lex();                               /* +/- yi geç */
    term();                              /* sonraki term */
  }
}

Kodlama kuralları: RHS'teki her terminal için sıradaki token'la karşılaştır (uymazsa hata); her nonterminal için onun alt programını çağır. Birden fazla RHS varsa doğru olanı lookahead token'a bakarak seç; hiçbiri uymuyorsa syntax error (factor() böyle yapar). Konvansiyon: her parsing rutini, sıradaki token'ı nextToken'da bırakır. Hocanın morali yüksek yorumu: "a recursive descent parser can be easily written... writing a compiler is not such a big issue."

Top-down parsing'in iki düşmanı var:

• Left recursion: grammar'da doğrudan ya da dolaylı sol recursion varsa top-down parser'a temel olamaz (expr() kendini sonsuz çağırırdı). Mekanik bir dönüşümle giderilebilir (hoca şemayı gösterip "that's too much into parsing" diyerek detayı atladı — sınavda mekaniği değil, kuralı bil).
• Pairwise disjointness eksikliği: Aynı nonterminal'in iki RHS'inin FIRST kümeleri (o RHS'ten türetilebilecek ilk terminal'ler) kesişmemeli (kesişim boş olmalı) — yoksa tek token lookahead ile hangi RHS'e gireceğini bilemezsin. (Dikkat: hoca derste cümleyi bir an ters kurdu; doğrusu budur ve örneği de doğru çözdü: A → a | aB ikisi de a ile başladığı için problemli.) Çözüm: left factoring — ortak baş kısmı dışarı al, kalanı yeni bir nonterminal'e taşı.

⭐ Bottom-up parsing ve LR ailesi

Bottom-up'ta problem tersine döner: eldeki sentential form'un içinde, bir önceki adıma dönmek için LHS'iyle değiştirilmesi (reduce edilmesi) gereken alt diziyi — handle'ı — bulmak. Tanım sınavlık: handle = right sentential form'un en soldaki simple phrase'i; parsing de "handle pruning" (budama) olarak düşünülebilir. Mekanizma shift-reduce:

• Shift: sıradaki token'ı parse stack'in tepesine taşı.
• Reduce: stack tepesindeki handle'ı, ait olduğu kuralın LHS'iyle değiştir.
• + Accept (parse tamam, hata yok) ve Error.

LR parser'ların avantajları: hemen tüm programlama dili grammar'larında çalışırlar, hataları mümkün olan en erken anda yakalarlar ve LR grammar sınıfı, LL ile parse edilebilenlerin üst kümesidir. Dezavantaj: tabloyu elle üretmek pratik değil — yacc/bison gibi araçlar üretir. Knuth'un içgörüsü: girdi ne kadar uzun olursa olsun olası parse durumu sayısı küçük ve sonludur; her durum bir state olarak stack'te saklanabilir. Tablo iki parçadır: ACTION (satır=state, sütun=terminal; hücreler S6="shift + state 6'yı push et", R4="kural 4 ile reduce") ve GOTO (satır=state, sütun=nonterminal; reduce sonrası hangi state'e geçileceği). Tablodaki boş hücreler = syntax error.

4 · Names, Bindings & Scopes

14 Temmuz oturumu — Ch.5 baştan sona bitirildi; ders sonunda Blackboard quizi yapıldı. (Data types, Lecture 5'e kaldı; attribute grammars ve semantik yöntemleri kesin olarak atlandı.)

Bu bölümün çatısı, Lecture 1'deki cümleye dayanıyor: imperative diller von Neumann mimarisinin soyutlamasıdır ve variable, bir bellek hücresinin soyutlamasıdır. Bu bölüm o soyutlamayı parçalarına ayırıyor. (Karşıt uç hatırlatması: saf fonksiyonel dillerde değişken hiç yok.)

İsimler: küçük görünen büyük tasarım soruları

• Uzunluk: çok kısa isim anlam taşıyamaz. Fortran I'de 6 karakterdi; C99'da sınır yok ama yalnızca ilk 63 karakter anlamlı (linker'ın gördüğü external isimlerde 31); Java/C#'ta hepsi anlamlı.
• Özel karakterler: PHP'de tüm değişkenler $ ile, Perl'de tipi belirten sigil'lerle ($ skaler, @ dizi, % hash), Ruby'de @ instance / @@ class değişkeni ile başlar.
• Case sensitivity: okunabilirliğe zarar verir — birbirine benzeyen isimler farklı şeylerdir. Hocanın örneği: C-tabanlı dillerde durum daha da kötü çünkü hazır isimler karışık büyük-küçük harfli (IndexOutOfBoundsException).
• ⭐ Special words: reserved word programcı tarafından yeniden tanımlanamaz; keyword yalnızca belirli bağlamlarda özeldir (Fortran'da keyword'ler değişken adı olarak kullanılabilir!). Çok fazla reserved word çakışma yaratır — COBOL'da 300 tane var; hocanın örneği: herkes length diye değişken ister ama COBOL izin vermez. (Sayıyı ezberleme; "çok fazla olursa problem" fikri yeter.)

⭐ Variable = altı nitelikli bir paket (sextuple)

Ezber adayı tanım — bir değişken şu altılıdır: name, address, value, type, lifetime, scope.

• Name: her değişkende olmayabilir (heap'teki isimsiz nesneler).
• Address: bağlı olduğu bellek adresi — aynı değişken farklı zamanlarda/yerlerde farklı adreste olabilir. İki isim aynı adrese erişebiliyorsa bunlar alias'tır (pointer, reference ve union'lar yaratır) — okunabilirlik düşmanı, çünkü bir değişkenin değeri başka bir isme atamayla değişebilir.
• ⭐ Value: hücrenin içeriği. Kritik çift: l-value = adres, r-value = değer. r-value'ya ulaşmak için önce l-value'yu bilmek gerekir.
• Type: değer aralığını ve geçerli işlemleri belirler — hocaya göre "the most important attribute" (Lecture 5'in konusu).
• Lifetime ve scope: aşağıda.

⭐⭐ Binding: her şeyin bir bağlanma zamanı var

Binding = bir varlık ile bir nitelik arasındaki ilişki (değişken↔tip, değişken↔değer, sembol↔işlem). Binding time = bu ilişkinin kurulduğu an. Beş klasik zaman:

Static binding: run time'dan önce kurulur ve program boyunca değişmez. Dynamic binding: çalışma sırasında kurulur ya da değişebilir. Hocanın tuzak uyarısı: dillerdeki static keyword'ü ile static binding aynı şey değildir — ilişkili ama farklı kavramlar.

⭐ Tip bağlama (type binding)

• Explicit declaration: int x; gibi bildirimle.
• Implicit declaration: kurala/geleneğe göre — Fortran'ın meşhur kuralı: I–N arası harfle başlayan isimler integer, gerisi real. Yazılabilirliğe küçük katkı, güvenilirliğe büyük zarar.
• Type inference: C# var a = 5; → int, var a = 5.0; → double; "the initial value sets the type." ML, Haskell, F#, VB 9+ da bağlamdan çıkarır.
• Dynamic type binding: tip, bildirimle değil atamayla gelir (JavaScript, Python, Ruby, PHP; C#'ta sınırlı dynamic). JavaScript örneği: list = [2, 4.33, 6, 8]; sonra list = 17.3; — aynı isim önce dizi, sonra skaler. Avantaj: esneklik (generic kod). Bedeli: sürekli çalışma zamanı tip kontrolü (maliyet) + derleyicinin tip hatası yakalayamaması. Ruby'de iş bir adım öte: tüm değişkenler tipsiz referanstır.

⭐ Lifetime: değişken ne zaman doğar, ne zaman ölür?

Lifetime = değişkenin bir bellek hücresine bağlı kaldığı süre: allocation ile başlar, deallocation ile biter. Dört kategori — her birinin avantaj/dezavantaj çifti sınavın eşleştirme klasiği:

⭐⭐ Scope: isim nereden görünür?

Scope = değişkenin görünür (okunabilir/atanabilir) olduğu deyimlerin aralığı. Bir birimde bildirilen değişkenler oranın local, görünüp de orada bildirilmemiş olanlar nonlocal değişkenleridir; global'ler nonlocal'in özel hâlidir.

⭐ Static scope

ALGOL 60'tan gelir; program metnine dayanır. Bir ismin hangi bildirime bağlanacağını bulmak için: önce lokale bak, bulamazsan bir dış katmana (static parent), sonra onun dışına (static ancestor'lar)... Aynı isimli daha "yakın" bir bildirim, dıştakini gizler (hiding/shadowing). Hocanın tam işlediği örnek:

function big() {
  var x = 3;
  function sub1() { var x = 7; ... sub2(); ... }
  function sub2() { ... x = 3; ... }   /* hangi x? */
  sub1();
}

Static scoping: sub2'de x bildirimi yok → dış katmana çık → big'in x'i (sub1'inki değil — metinsel kapsayan sub1 değil big'dir). Diğer araçlar: blocks (ALGOL 60 mirası; C/C++'ta iç blokta aynı isimle değişken gizleme legal, Java/C#'ta hataya açık diye yasak), fonksiyonel dillerin LET construct'ları (ilk kısım isimleri değerlere bağlar, ikinci kısım kullanır), C99/C++/Java/C#'ta bildirimin herhangi bir yerde yapılabilmesi (scope bildirimden blok sonuna; C#'ın "tüm blok" diyen dokümantasyonu yanıltıcıdır — yine de kullanmadan önce bildirmek zorundasın), for içinde bildirim (scope = for gövdesi).

Global scope ayrıntıları: C/C++'ta declaration (yalnız nitelik bildirir — extern int x;) ile definition (bellek de ayırır) farklıdır; istediğin kadar uyumlu declaration, ama yalnızca tek definition. PHP'de fonksiyon içinden global'e erişim $GLOBALS dizisi ya da global bildirimiyle; Python'da global bir değişkene fonksiyon içinde atama yapmak için global (iç içe fonksiyonlarda bir üst katman için nonlocal) gerekir.

Static scoping eleştirisi: çoğu durumda gereğinden fazla erişim verir; program evrildikçe yapı bozulur — lokaller globalleşir ("developers discard structure when it gets in the way").

⭐ Dynamic scope

Metne değil çağrı zincirine dayanır — hocanın sloganıyla "temporal versus spatial" (zaman, mekâna karşı). İsim, o ana kadarki çağrı zincirinde geriye doğru aranır. Aynı örnekte: big → sub1 → sub2 çağrı sırasıyla gelindiyse, sub2'deki x sub1'in x'idir (en son aktif bildirim). Avantajı pratiklik (parametre taşımak gerekmez); bedelleri ağır: çağıran her şeyin değişkenleri görünür (güvenilirlik ↓), static type checking imkânsız, okunabilirlik kötü, erişim yavaş.

int ver() {
  static int k;      /* k: fonksiyon dışından GÖRÜNMEZ (scope)   */
  k = k + 5;         /*    ama çağrılar arasında YAŞAR (lifetime) */
  return k;
}

Referencing environment: bir deyimde görünür tüm isimlerin kümesi. Static-scoped dilde = lokaller + tüm kapsayan scope'ların görünür değişkenleri; dynamic-scoped dilde = lokaller + tüm aktif (başlamış, bitmemiş) alt programların görünür değişkenleri.

⭐ Named constants: yalnızca bir kez, bellek bağlanırken değer bağlanan "değişkenler" — okunabilirlik ve değiştirilebilirlik için (programı parametrize eder). Değer bağlama static ise manifest constant denir. C# ayrımı sınavlık: const → compile time'da, readonly → çalışma zamanında (dinamik) bağlanır.

Vize Deneme Sınavı

Hocanın ilan ettiği vize formatında (10–15 çoktan seçmeli + 3–5 açık uçlu). Her soru, derste vurgulanan bir noktadan türetildi; cevapların altında kaynağı da yazıyor. Önce kendin çöz, sonra "Cevabı göster"e tıkla.

Bölüm A — Çoktan seçmeli

Bölüm B — Açık uçlu

<program> → <stmts>
<stmts>   → <stmt> | <stmt> ; <stmts>
<stmt>    → <var> = <expr>
<var>     → a | b | c | d
<expr>    → <term> + <term> | <term> - <term>
<term>    → <var> | const

<program> => <stmts> => <stmt> => <var> = <expr> => d = <expr>
=> d = <term> - <term> => d = <var> - <term> => d = c - <term> => d = c - const ✓

function big() {
  var x = 3;
  function sub1() { var x = 7; ... sub2(); ... }
  function sub2() { ... x = 3; ... }
  sub1();
}

Vize Soru Havuzu

Deneme sınavının devamı: transkriptlerden çıkan, hocanın sorabileceği her şey — ders ders. Soruya tıkla, cevabı açılır.

⭐ = hocanın doğrudan söylediği, tekrarladığı veya "important" dediği noktaya dayanıyor; önce bunları bitir. Yıldızsızlar tamamlayıcı — vakit kalırsa.

⭐⭐ Quiz 1'in GERÇEK soruları (14 Temmuz, Blackboard)

Hocanın soru stilinin birebir örneği — vize çoktan seçmelileri büyük olasılıkla bu kalıpta olacak. (Sonuç: 90/100; yalnız Q8 gitti.)

Lecture 1 — Giriş & Motivasyon

Lecture 2 — Dillerin Evrimi

Lecture 3 — Syntax, Semantics & Parsing

Lecture 4 — Names, Bindings & Scopes

Final Sınav Radarı

Vize sonrası altı dersin (Lecture #5–#10) transkriptleri, slaytları ve syllabus çapraz okunarak çıkarılan analiz. 10 Ağustos son dersiyle güncellendi.

Ağırlıklar ve not durumun

Ne demek: Final tek başına notun %40'ı — vizeyle eşit ağırlıkta. Syllabus'un dediği gibi ders içi etkinlikler %60, final %40.

Format — artık tahmin değil, hocanın teyidi

En olası 26 soru konusu — öncelik sırasıyla

Aşağıdaki sıralama şu üç sinyalin kesişiminden çıkarıldı: (a) hocanın sözlü vurgusu ("very important", "the main difference", "remember"), (b) slaytta ayrı bir sayfaya veya kutuya konmuş olması, (c) hocanın vize formatındaki "karşılaştırma" kalıbına uygunluk.

Tekrar eden temalar — dersin "omurgası"

Çalışma planı — sırayla

1. Önce tanımlar. Her bölümdeki "birebir ezber" kutularını çıkar: data type, descriptor, object, array, record, associative array, union, pointer, type checking, coercion, strong typing, profile, protocol, closure, coroutine, activation record, ADT'nin iki koşulu, abstraction, naming encapsulation, message / message protocol, subtype, polymorphic variable, abstract method & abstract class, CIR, vtable. Quiz 1'in dersi: slayttaki ifadeyle.
2. Sonra karşılaştırma tabloları. Yukarıdaki 20 maddelik listenin her satırı için iki sütunlu bir tablo kur ve kapalı kitap yaz.
3. Sonra "hangi dil ne yapar" tabloları. Bunlar MC'nin ana kaynağı. Özellikle: C/C++'ın istisnaları, Java'nın yokları (union yok, goto yok, destructor yok, metot parametresi yok), Ada'nın ayrıcalıkları (dönüş tipiyle overload ayrımı, coercion yok, in/out/inout), ML/F#'ın katılığı (coercion yok).
4. En son sayısal/kodlu örnekler. Access function hesabı, (chain_offset, local_offset), fun1() side effect çıktısı, C# parameter collision. Bunlar az sayıda ama ayırt edici sorulardır.
5. Soru havuzunu çöz (aşağıda) ve yanlışlarını ilgili bölüme dönerek kapat.

5 · Data Types

Ch.6 · 21 Temmuz dersi (tek oturumda iki haftalık konu) · Slayt: Lecture #5 — finalin en büyük ve en yoğun bölümü

Temel tanımlar — ezberlenecek üçlü

Bölümün ilk üç slaydı doğrudan tanım sorusu malzemesi. Hoca üçünü de tek tek okudu:

Neden tip sistemi? — hocanın "üç önemli şey"i

Slaytta olmayan ama hocanın uzun uzun anlattığı bir çerçeve. "Three important things come into mind" dedi ve error detection'ı 1. sıraya koydu. Açık uçlu soru adayı:

1. Error detection (hata yakalama) — en pratik gerekçe. type checking süreci doğrudan tip sistemi tarafından yönetilir.
2. Modularization (modülerleştirme) — modüller arası (cross-module) tip denetimi, arayüzlerin tutarlılığını garanti eder → yeniden kullanılabilirlik.
3. Documentation (belgeleme) — tip bildirimleri programın verisi hakkında bilgi belgeler, davranışı hakkında ipucu verir.

Primitive data types

Tanım: Başka veri tipleri cinsinden tanımlanmayan tipler. Bazıları doğrudan donanımın yansımasıdır, bazıları küçük bir yazılım desteği ister. Hocanın benzetmesi: primitive tipler alfabe, yapısal tipler o alfabeyle kurulan kelimeler ve cümleler.

Integer

• Neredeyse her zaman donanımın birebir yansıması → eşleme (mapping) trivial.
• Bir dilde sekiz kadar farklı integer tipi olabilir. Java'nın işaretli boyutları: byte, short, int, long.
• C/C# ayrıca unsigned tipler sunar (ikili veri için kullanışlı). Java'da unsigned yok.

Floating point

• Gerçek sayıları modeller ama yalnızca yaklaşık olarak. Matematikte sayılar sürekli, bilgisayarda ayrık.
• π ve e gibi sonsuz sayılar sonlu bellekte tam gösterilemez — terabaytlarca bellek olsa da.
• Ondalık→ikili dönüşüm de sorunlu: 0.1 (decimal) ikili tabanda 0.000110011001100… şeklinde devreder.
• Bilimsel kullanım için dil en az iki tip sunmalı: float ve double.
• IEEE Floating-Point Standard 754 — sayıyı üç parçaya böler:

  Parça	32-bit	64-bit
  sign (işaret)	1 bit	1 bit
  exponent (üs)	8 bit	11 bit
  fraction (kesir)	23 bit	52 bit

• precision = kesir kısmının doğruluğu (bit cinsinden) · range = kesir aralığı + üs aralığının birleşimi. Bu ikisini karıştırma.

Complex ve Decimal

Boolean ve Character

• Boolean: hepsinin en basiti, iki değer. Bit ile gösterilebilir ama çoğunlukla byte kullanılır. En büyük avantajı: readability. ALGOL 60'ta tanıtıldı.
  İstisna: C89'un boolean tipi yoktu — sayısal ifadeleri koşul olarak kullandı (0 = false, sıfırdan farklı = true). C99/C++'ta boolean var ama sayısal ifade de hâlâ koşul olabiliyor; Java ve C#'ta olamaz.
• Character: sayısal kodlama olarak saklanır.

  Kodlama	Genişlik	Not
  ASCII	0–127 (128 karakter)	En yaygın; İngilizce için yeterliydi
  Unicode UCS-2	16 bit	Çoğu doğal dilin karakteri. Orijinal olarak Java'da kullanıldı. İlk 128 karakteri ASCII ile birebir aynı.
  Unicode UCS-4	32 bit	Fortran, 2003'ten itibaren

Character string types

Tanım: değerleri karakter dizileri olan tip. İki tasarım sorusu var — hoca "the two important issues" dedi:

Tipik işlemler: assignment/copying · comparison (=, >) · catenation (birleştirme) · substring reference · pattern matching.
Not: substring reference, array'lerde slice adını alacak — aynı fikrin iki adı.

Uzunluk seçenekleri — üç kategori

Ordinal ve enumeration types

Ordinal type: olası değerler kümesi pozitif tamsayılarla kolayca eşleştirilebilen tip. Java'daki primitive ordinal örnekleri: integer, char, boolean.

Enumeration type: tüm olası değerler, tanımda isimlendirilmiş sabitler olarak verilir. enum days {mon, tue, wed, thu, fri, sat, sun}; — içeride örtük olarak 0,1,2… atanır ama açıkça da atanabilir.

Üç tasarım sorusu: (1) bir enum sabiti birden fazla tip tanımında görünebilir mi, görünürse tipi nasıl denetlenir? (2) enum değerleri integer'a coerce edilir mi? (3) başka tipler enum'a coerce edilir mi?
Hocanın notu: "all these design issues are somehow related to type checking".

Array types

Tanım (birebir ezberlenecek): array, homogeneous bir veri elemanı topluluğudur; her eleman ilk elemana göre konumuyla (position) tanımlanır.

Array'in dört kategorisi — en olası sınav sorusu

Kategoriler üç şeye göre belirlenir: subscript aralıklarının bind'ı, storage'ın bind'ı, storage'ın nereden ayrıldığı.

Array'in diğer özellikleri

• Heterogeneous array: elemanları aynı tipte olmak zorunda değil → Perl, Python, JavaScript, Ruby.
• Rectangular: tüm satırlar eşit uzunlukta. Jagged (ragged): satırlar farklı uzunlukta — array of arrays olduğunda mümkün.
  C, C++, Java jagged destekler. F# ve C# ikisini de destekler.
• Slice: bir array'in alt yapısı; "bir referanslama mekanizmasından başka bir şey değildir". Yalnızca array işlemleri olan dillerde anlamlıdır. Python vector[3:6], Ruby list.slice(2,2).
• APL vektör/matris işlemlerinde en güçlü operatör setini sunar. Fortran elemental işlemler sağlar: A = A + B iki array'in eleman çiftlerini toplar.

Array implementasyonu — access function

Tek boyutlu için erişim fonksiyonu:

address(list[k]) = address(list[lower_bound])
                 + ((k − lower_bound) × element_size)

Çok boyutlu için iki yerleşim düzeni var — bu ayrım kesin bilinmeli:

Location(a[i,j]) = address(a[row_lb, col_lb])
                 + (((i − row_lb) × n) + (j − col_lb)) × element_size

Associative arrays

Tanım: sırasız bir veri elemanı topluluğu; elemanlar key denen eşit sayıda değerle indekslenir. Kullanıcı tanımlı key'ler saklanmak zorundadır (normal array'de indeks saklanmaz — fark bu).

Tasarım soruları: elemanlara referansın biçimi ne? Boyut static mi dynamic mi?

Yerleşik tip olduğu diller: Perl, Python, Ruby, Swift.

Record types

Tanım: possibly heterogeneous bir veri elemanı topluluğu; elemanlar isimleriyle tanımlanır. (Array ile karşıtlığı buradan kur: array homojen + konumla, record heterojen + isimle.)

Tasarım soruları: alan referansının sözdizimsel biçimi nedir? Elliptical reference'a izin var mı?

Fully qualified reference: tüm record isimlerini içerir. Elliptical reference: belirsizlik olmadığı sürece record isimlerinin atlanmasına izin verir — COBOL'da FIRST, FIRST OF EMP-NAME ve FIRST OF EMP-REC üçü de aynı alana elliptical referanstır.

Tuple ve List types

Python listeleri: array görevi de görür; Scheme/Lisp/ML/F#'ın aksine mutable; elemanlar herhangi tipte olabilir; indeks 0'dan başlar; del ile eleman silinir.
List comprehension: küme gösteriminden türetilmiştir. Orijinali Haskell'ındır: [n * n | n <- [1..10]]. Python: [x * x for x in range(6) if x % 3 == 0] → [0, 9].

Union types

Tanım: değişkenlerinin çalışma sırasında farklı zamanlarda farklı tipte değerler saklamasına izin veren tip. (Hocanın vurgusu: during execution, not compilation.)

Tasarım soruları: type checking gerekli mi? Union'lar record'ların içine gömülmeli mi?

Pointer ve Reference types

Pointer tanımı: değer aralığı bellek adresleri + özel bir nil değeri olan tip. İki şey sağlar: indirect addressing gücü ve dinamik belleği yönetme yolu.

Beş tasarım sorusu: pointer değişkeninin scope/lifetime'ı nedir? · heap-dynamic değişkenin lifetime'ı nedir? · pointer'lar işaret edecekleri tip bakımından kısıtlı mı? · pointer'lar dinamik depolama yönetimi için mi, indirect addressing için mi, ikisi için mi? · dil pointer mı, reference mı, ikisini de mi desteklemeli?

İki temel işlem: assignment (pointer'a yararlı bir adres atamak) ve dereferencing (pointer'ın gösterdiği yerdeki değeri almak). Dereferencing explicit (C++: j = *ptr) veya implicit olabilir.

Dangling pointer'a iki çözüm

C/C++ pointer'ları

• Son derece esnek ama dikkatle kullanılmalı — hoca "assembly'deki adresler gibi" dedi.
• Nerede/ne zaman ayrılmış olursa olsun herhangi bir değişkeni gösterebilir.
• Pointer arithmetic mümkün: *(p+5) ≡ stuff[5] ≡ p[5].
• Domain type sabit olmak zorunda değil: void * herhangi bir tipi gösterebilir, type checked edilebilir ama dereference edilemez.

Reference types

Heap management ve garbage collection

Çok karmaşık bir run-time süreci. İki eksen: single-size cells vs variable-size cells. Çöp toplamada iki yaklaşım var — bu ikili neredeyse kesin sorulur:

Optional types

Bir değişkenin şu anda değeri olmadığını belirtmesi gerektiğinde kullanılır. C#, F#, Swift destekler. C#'ta reference tipler zaten optional'dır (null); value type'lar (struct) tip adına soru işareti eklenerek optional yapılır: int? x;. Değersizlik null'dır; Swift'te nil kullanılır.

Type checking, strong typing, type equivalence

Static/dynamic bağlantısı: tüm tip binding'leri static ise type checking'in neredeyse tamamı static yapılabilir. Binding'ler dynamic ise type checking de dynamic olmak zorundadır.

Strong typing: bir dil, tip hataları her zaman yakalanıyorsa strongly typed'dır. Avantajı: tip hatasına yol açan değişken yanlış kullanımlarının saptanabilmesi.

Type equivalence — iki yaklaşım

Structure equivalence'ın açık soruları: alan adları farklı ama yapı aynı olan iki record eşdeğer mi? Yalnızca subscript'leri farklı ([1..10] ve [0..9]) iki array tipi eşdeğer mi? Bileşenleri farklı yazılmış iki enum eşdeğer mi?

6 · Expressions, Assignment & Control Structures

Ch.7–8 · 27 Temmuz dersi · Slayt: Lecture #6 (iki parçalı) — vizeden sonraki ilk konu

Aritmetik expression'ların 6 tasarım sorusu

Operatör aritesi: unary = 1 operand · binary = 2 operand · ternary = 3 operand. Hoca bunu ayrıca "remember that" diye tekrarladı.
Çoğu dilde binary operatörler infix; Scheme ve LISP'te prefix (Perl'de de bazı prefix binary'ler var). Çoğu unary operatör prefix, ama C tabanlı dillerde ++ ve -- hem prefix hem postfix olabilir.

Precedence ve associativity

Tipik öncelik sırası: parantez → unary operatörler → ** (varsa) → *, / → +, -
Tipik associativity: soldan sağa; ama ** sağdan sola. Fortran'da unary operatörler bazen sağdan sola.
APL istisnası (kesin sınav malzemesi): tüm operatörlerin önceliği eşittir ve hepsi sağdan sola associate eder.
Her ikisi de parantezle ezilebilir.

Conditional expression (C tabanlı diller): average = (count == 0) ? 0 : sum / count — bir if-else'e denk ama ifade olduğu için değer üretir.

Operand değerlendirme sırası ve side effect'ler

Operand değerlendirmenin dört durumu: (1) değişkenler — bellekten fetch; (2) sabitler — bazen bellekten, bazen doğrudan makine komutunun içinde; (3) parantezli ifadeler — önce tüm operand ve operatörler değerlendirilir; (4) en ilginç durum: operand bir fonksiyon çağrısı olduğunda.

int a = 5;
int fun1() {
    a = 17;
    return 3;
}
int main() {
    a = a + fun1();
    printf("%d\n", a);
}

Side effect'e iki çözüm

Referential transparency

result1 = (fun(a) + b) / (fun(a) − c);

temp = fun(a);
result2 = (temp + b) / (temp − c);

Overloaded operators

Tanım: Bir operatörün birden fazla amaçla kullanılması. Bazıları yaygın ve zararsız (+ hem int hem float için); bazıları sorunlu.

Kullanıcı tanımlı operator overloading: C++, C#, F# (ve Ada, Python, Ruby) izin verir.
Makul kullanılırsa okunabilirliğe katkıdır (metot çağrısından kaçınılır, ifade doğal görünür).
Riskleri: kullanıcı anlamsız işlemler tanımlayabilir (hocanın örneği: +'yı çarpma yapmak); operatörler anlamlı olsa bile okunabilirlik zarar görebilir.

Tarihsel not (hoca "very interesting" dedi): Operator overloading, C++'ın Java'ya kopyalanmayan özelliklerinden biridir — ama sonra C#'a girmiştir. C++'ta bazı operatörler overload edilemez: sınıf/struct üye operatörü . ve scope resolution ::.

Type conversions

Mixed-mode expression: operand'ları farklı tipte olan ifade.
Coercion: örtük (implicit) tip dönüşümü — derleyici ya da run-time sistemi başlatır.
Neden gerekir? Hocanın açıklaması: bilgisayarlarda farklı tipte operand alan ikili işlem yoktur, o yüzden mixed-mode'a izin veren dil örtük dönüşüm kuralları tanımlamak zorundadır.

Coercion'ın dezavantajı: derleyicinin tip hatası yakalama yeteneğini azaltır.

Explicit conversion (cast): C tabanlı dillerde "casting" denir. C: (int)angle · F#: float(sum) — F#'ın sözdizimi fonksiyon çağrısına benzer.

Expression hataları

İki kaynak: (1) aritmetiğin doğasındaki sınırlar — sıfıra bölme; (2) bilgisayar aritmetiğinin sınırları — overflow.
Overflow: sonuç register'a sığmayacak kadar büyük · Underflow: sığmayacak kadar küçük.
Bunlar run-time error'dır ve çoğu zaman run-time sistem tarafından görmezden gelinir. Bu hatalara bazen exception denir (Ch.14'ün konusu).

Relational ve Boolean expressions

• Relational expression: ilişkisel operatörler + çeşitli tiplerde operand → sonuç bir Boolean gösterimi. Eşitsizlik sembolü diller arasında çok değişir: !=, /=, ~=, .NE., <>, #.
• JavaScript ve PHP'de fazladan === ve !== var — ==/!= gibi ama operand'larını coerce etmezler. Ruby'de aynı ayrım: == coercion yapar, eql? yapmaz.
• C89'un Boolean tipi yoktur — int kullanır (0 false, sıfırdan farklı true).

Short-circuit evaluation

index = 0;
while (index <= length) && (LIST[index] != value)
        index++;

Yan etki riski: short-circuit, ifadelerdeki side effect problemini açığa çıkarır: (a > b) || (b++ / 3) — a > b doğruysa b++ hiç çalışmaz.

Assignment statements

Genel sözdizimi: <target_var> <assign_operator> <expression>
Operatör: = (Fortran, BASIC, C tabanlı) · := (Ada).
='in eşitlik ilişkisel operatörüyle overload edilmesi kötüdür — C tabanlı diller tam bu yüzden =='i ilişkisel operatör yaptı.

"Assignment as expression"in dezavantajı: bir başka tür expression side effect'i.

Fonksiyonel dillerde atama ve mixed-mode assignment

Fonksiyonel dillerde tanımlayıcılar yalnızca değerlerin isimleridir. ML: isimler val ile değere bağlanır (val fruit = apples + oranges;); aynı isim için ikinci bir val gelirse bu yeni ve farklı bir isimdir. F#: let, ML'in val'i gibidir ama ayrıca yeni bir scope yaratır.

Part 2 — Statement-Level Control Structures

Control structure tanımı: bir kontrol deyimi ve onun çalışmasını yönettiği deyimler.
Tasarım sorusu: bir kontrol yapısının birden çok girişi olmalı mı?

Selection statements

Tanım: iki veya daha çok yürütme yolu arasında seçim yapma aracı. İki kategori: two-way selector ve multiple-way selector.

Two-way'in üç tasarım sorusu: kontrol ifadesinin biçimi ve tipi nedir? · then/else clause'ları nasıl belirtilir? · iç içe seçicilerin anlamı nasıl belirtilmeli?

• Kontrol ifadesi aritmetik olabilen diller: C89, C99, Python, C++. Diğer çoğu dilde Boolean olmak zorunda.
• Perl: tüm clause'lar süslü parantezle sınırlanmak zorunda (compound olmalı).
• Python ve Ruby: clause'lar deyim dizileridir; Python girintiyle (indentation) tanımlar.

if (sum == 0)
    if (count == 0)
        result = 0;
else result = 1;

if (sum == 0) {
    if (count == 0)
        result = 0;
}
else result = 1;

Multiple-way selection (switch/case)

Beş tasarım sorusu: kontrol ifadesinin biçimi/tipi? · seçilebilir segmentler nasıl belirtilir? · akış tek bir segmentle sınırlı mı? · case değerleri nasıl belirtilir? · temsil edilmeyen değerler ne olur?

Ruby'nin iki case biçimi: (1) when + Boolean ifadeler; (2) bir case değeri + when değerleri.
if ile multiple-way: else-if zinciri — Python'da elif.

Iterative statements

Tekrar, iteration ya da recursion ile sağlanır. İki genel tasarım sorusu: iterasyon nasıl kontrol edilir? · kontrol mekanizması döngünün neresinde?

Counter-controlled loop: bir loop değişkeni + başlangıç, bitiş ve adım (stepsize) değerlerini belirtme yolu.
Üç tasarım sorusu: loop değişkeninin tipi ve scope'u? · loop değişkeni/parametreleri gövdede değiştirilebilir mi, değiştirilirse kontrolü etkiler mi? · loop parametreleri bir kez mi yoksa her iterasyonda mı değerlendirilir?

Python'ın for'u: for loop_variable in object: — object çoğunlukla bir range'tir. İsteğe bağlı bir else clause'u vardır ve döngü normal biçimde sonlanırsa çalışır.

Logically-controlled loop: tekrar bir Boolean ifadeye dayanır (sayaca değil). İki tasarım sorusu: pretest mi posttest mi? · mantıksal döngü, sayma döngüsünün özel hâli mi olmalı yoksa ayrı bir deyim mi?

• C, C++: hem pretest (while) hem posttest (do…while); kontrol ifadesi aritmetik olabilir; gövdeye dallanmak yasaldır.
• Java: C/C++ gibi ama kontrol ifadesi Boolean olmalı, gövdeye yalnızca baştan girilebilir — Java'da goto yoktur.
• Perl ve Ruby: iki pretest mantıksal döngü — while ve until. Perl'de ayrıca iki posttest döngü var.

Veri yapısına dayalı iterasyon (iterator): iterasyon sayısını veri yapısındaki eleman sayısı belirler. Kontrol mekanizması, seçilen sırada bir sonraki elemanı döndüren bir iterator fonksiyonu çağrısıdır; eleman kalmazsa döngü biter.

Unconditional branching (goto)

7 · Subprograms

Ch.9 · 28 Temmuz dersi (Quiz 2 bu derste yapıldı) · Slayt: Lecture #7

İki temel soyutlama — dersin çatısı

Hocanın eklediği kritik cümle: bugün ikisi eşit derecede önemli soyutlamalar sayılır. Bu, "process vs data abstraction" karşılaştırma sorusunun cevabıdır.

Subprogram'ların üç temel özelliği

Temel tanımlar — tanım sorusu deposu

Dil istisnaları (tek tek sorulabilir):

• Python: fonksiyon tanımları çalıştırılabilirdir (executable) — diğer tüm dillerde çalıştırılabilir değildir.
• Ruby: fonksiyon tanımları sınıf tanımının içinde veya dışında olabilir; dışındaysa Object'in metodudur ve nesnesiz çağrılabilir.
• Lua: tüm fonksiyonlar anonimdir.

Actual/Formal parametre karşılığı

Default değerler: C++, Python, Ruby, Ada, PHP formal parametrelere varsayılan değer verebilir. C++'ta default parametreler en sonda olmak zorundadır — çünkü parametreler konumsal olarak eşleşir.

Procedure vs Function

Subprogram tasarım soruları (11 madde)

Hoca "subprogram'lar karmaşık yapılardır, bu yüzden çok soru var" dedi. Liste:

1. Local değişkenler static mi dynamic mi?
2. Subprogram tanımları başka subprogram tanımlarının içinde görünebilir mi? (nesting)
3. Hangi parameter passing yöntemleri sunuluyor?
4. Parametre tipleri denetleniyor mu?
5. Subprogram'lar parametre olarak geçirilebiliyor ve nesting varsa, geçirilen subprogram'ın referencing environment'ı nedir?
6. Functional side effect'lere izin var mı?
7. Fonksiyonlardan hangi tipte değerler dönebilir?
8. Fonksiyonlardan kaç değer dönebilir?
9. Subprogram'lar overload edilebilir mi?
10. Subprogram'lar generic olabilir mi?
11. Nesting varsa closure destekleniyor mu?

Local referencing environments

Diller: çoğu çağdaş dilde local'ler stack-dynamic'tir. C tabanlı dillerde varsayılan stack-dynamic ama static ile bildirilebilir. C++, Java, Python ve C#'ın metotlarında yalnızca stack-dynamic local'ler vardır.

int adder(int list[], int listlen) {
  static int sum = 0;     // static
  int count;              // stack dynamic
  for (count = 0; count < listlen; count++)
      sum += list[count];
  return sum;
}

Parameter passing — semantik modeller

Beş parameter passing yöntemi — bu bölümün kalbi

void Fixer(out int x, out int y) {
  x = 17;
  y = 35;
}
f.Fixer(out a, out a);

Ek soru: geçirilen referans, çağrılan subprogram'da değiştirilebilir mi?
C'de mümkündür (bu yüzden C'de altprogram yazımını takip etmek zorlaşır).
Pascal ve C++'ta adres olan formal parametreler örtük olarak dereference edilir → bu tür değişiklikler engellenir.

Parameter passing'in gerçeklenmesi

Çoğu dilde parametre iletişimi run-time stack üzerinden olur. Pass-by-reference gerçeklemesi en kolayıdır — stack'e yalnızca bir adres konur. Pass-by-value'da değerler stack konumlarına kopyalanır ve o konumlar formal parametrelerin deposu olur. Pass-by-result, pass-by-value'nun tersidir.

Büyük dillerin parameter passing yöntemleri

Parametrelerin tip denetimi

Reliability için çok önemli sayılır. Hoca ısrarla tekrarladı.

Çok boyutlu array'lerin parametre olarak geçirilmesi

Parameter passing'in tasarım gerilimi

Parametre olarak subprogram adları

İki mesele: (1) parametre tipleri denetleniyor mu? (2) parametre olarak gönderilen subprogram için doğru referencing environment nedir?

• C ve C++: fonksiyonlar parametre olarak geçirilemez ama fonksiyon pointer'ları geçirilebilir ve tipleri parametre tiplerini de içerdiği için tip denetimi yapılabilir.
• Java, metot adlarının parametre olarak geçirilmesine izin vermez.

Subprogram'ları dolaylı çağırma

Ne zaman gerekir: çağrılabilecek birkaç subprogram varsa ve doğru olanı çalışma zamanına kadar bilinmiyorsa — tipik örnek: event handling ve GUI'ler.

• C/C++: function pointer'lar üzerinden.
• C#: metot pointer'ları delegate denen nesneler olarak gerçeklenir. public delegate int Change(int x); — int alıp int döndüren herhangi bir metotla örneklenebilir. Bir delegate birden fazla adres tutabilir → buna multicast delegate denir.

Fonksiyonlar için tasarım soruları

Side effect'lere izin var mı? — Ada gibi parametreler side effect'i azaltmak için her zaman in-mode olmalı.

Overloaded ve Generic subprograms

Overloaded subprogram: aynı referencing environment'ta başka bir subprogram'la aynı ada sahip subprogram. Her versiyonun benzersiz bir protokolü vardır.
C++, Java, C#, Ada önceden tanımlı overloaded subprogram'lar içerir ve kullanıcının da yazmasına izin verir.
Ada'nın ayrıcalığı: overloaded bir fonksiyonun dönüş tipi çağrıları ayırt etmek için kullanılabilir → yani Ada'da iki overloaded fonksiyon aynı parametrelere sahip olabilir. Diğer dillerde olamaz.

Kullanıcı tanımlı overloaded operatörler: Ada, C++, Python, Ruby. Python örneği: def __add__(self, second): — x + y aslında x.__add__(y)'dir.

Closures

function makeAdder(x) {
   return function(y) {return x + y;}
}
var add10 = makeAdder(10);
var add5  = makeAdder(5);
add10(20)  // 30
add5(20)   // 25

Coroutines

8 · Implementing Subprograms

Ch.10 · 3 Ağustos dersi (elektrik kesintisi nedeniyle asenkron kayıt) · Slayt: Lecture #8

Subprogram linkage — genel semantik

Tanım: Bir dilin subprogram çağrı ve dönüş işlemlerine birlikte subprogram linkage denir.

"Simple" subprogram'ların gerçeklenmesi

Gerekli depolama: status bilgisi · parametreler · dönüş adresi · (fonksiyonsa) dönüş değeri · geçici değerler (temporaries).

Stack-dynamic local değişkenlerle gerçekleme

Activation record daha karmaşık olur çünkü:

• Derleyici, local değişkenlerin örtük allocation/deallocation'ı için kod üretmelidir.
• Recursion desteklenmelidir — bu, bir subprogram'ın aynı anda birden çok etkinleşmesi olasılığını ekler.

Gözden geçirilmiş çağrı/dönüş eylemleri

Dynamic chain ve local_offset

int factorial(int n) {
  if (n <= 1) return 1;
  else return (n * factorial(n − 1));
}
void main() {
  int value;
  value = factorial(3);
}

Nested subprograms

Bazı C tabanlı olmayan static-scoped diller (Fortran 95+, Ada, Python, JavaScript, Ruby, Swift) stack-dynamic local kullanır ve subprogram'ların iç içe olmasına izin verir.

Temel gerçek: non-local erişilebilen tüm değişkenler, stack'teki bir ARI'nın içindedir.

Static chain — static scoping'in gerçeklenmesi

Static chain bakımı ve değerlendirmesi

Çağrı anında: ARI kurulmalı · dynamic link zaten eski stack top pointer'ıdır · static link, static parent'ın en güncel ARI'sını göstermelidir. İki yöntem: (1) dynamic chain'i ara; (2) subprogram çağrı ve tanımlarını, değişken referans ve tanımları gibi ele al.

Blocks

Tanım: Değişkenler için kullanıcının belirlediği local scope'lar.

{ int temp;
  temp = list[upper];
  list[upper] = list[lower];
  list[lower] = temp;
}

Dynamic scoping'in gerçeklenmesi

9 · Abstract Data Types & Encapsulation

Ch.11 · 4 Ağustos dersi (Quiz 3 bu derste yapıldı) · Slayt: Lecture #9 · elindeki son kayıt

Abstraction kavramı

Abstract data type — iki koşullu tanım

Avantajlar — hangi koşuldan hangi avantaj geliyor

Dilin ADT için sağlaması gerekenler (üç madde):

1. Tip tanımını kapsülleyecek bir sözdizimsel birim
2. Tip adlarını ve subprogram header'larını istemcilere görünür kılan, ama asıl tanımları gizleyen bir yöntem
3. Bazı ilkel işlemlerin dil işlemcisinin içine gömülü olması

Üç tasarım sorusu: Abstract tipler parametreleştirilebilir mi? · Hangi erişim denetimleri sunuluyor? · Tipin spesifikasyonu, gerçeklemesinden fiziksel olarak ayrı mı?

Dil örneği: C++

• Temeli: C'nin struct tipi + Simula 67'nin sınıfları. (Simula 67 vurgusu vizedeki tarih dersinin devamı.)
• class kapsülleme aracıdır. Bir sınıf bir tiptir.
• Bir sınıfın tüm örnekleri üye fonksiyonların tek bir kopyasını paylaşır; ama her örneğin kendi veri üyeleri kopyası vardır. (Bu ayrım çok sorulur.)
• Örnekler static, stack dynamic veya heap dynamic olabilir.

Constructor ve Destructor

class Stack {
  private:
       int *stackPtr, maxLen, topPtr;
  public:
       Stack() {                  // constructor
               stackPtr = new int[100];
               maxLen = 99;
               topPtr = -1;
       };
       ~Stack() {delete [] stackPtr;};   // destructor
       void push(int number) { … };
       void pop() { … };
       int  top() { … };
       int  empty() { … };
}

friend: C++ bazı ilgisiz birim veya fonksiyonlara private üyelere erişim vermek için friend fonksiyon/sınıflarını sunar — slaytın notu: "Necessary in C++".

Dil örneği: Java

Dil örneği: C#

• C++ ve Java temelli.
• İki erişim belirteci ekler: internal ve protected internal.
• Tüm sınıf örnekleri heap dynamic'tir.
• Tüm sınıflar için varsayılan constructor vardır.
• Çoğu heap nesnesi için garbage collection kullanılır, destructor nadiren kullanılır.
• struct'lar, inheritance'ı desteklemeyen hafif sınıflardır.

public class Weather {
   public int DegreeDays {          // property
      get { return degreeDays; }
      set {
        if (value < 0 || value > 30)
           Console.WriteLine("Value is out of range: {0}", value);
        else degreeDays = value; }
   }
   private int degreeDays;
}
…
w.DegreeDays = degreeDaysToday;   // setter çalışır
oldDegreeDays = w.DegreeDays;     // getter çalışır

Dil örneği: Ruby

Parameterized ADTs (generic classes)

Encapsulation constructs

Naming encapsulations

Sorun: Büyük programlar çok sayıda global isim tanımlar; bunları mantıksal gruplara ayırmanın yolu gerekir.
Tanım: Bir naming encapsulation, isimler için yeni bir scope yaratmak üzere kullanılır.

10 · Support for Object-Oriented Programming

Ch.12 · 10 Ağustos dersi (Quiz 4 dersin hemen ardından) · Slayt: Lecture #10 · dönemin son dersi

⭐⭐ OOP'nin üç dayanağı ve temel kavramlar

⭐ Inheritance — neden icat edildi?

Bir subclass ebeveyninden üç şekilde farklılaşabilir

⭐⭐ Dynamic binding (polymorphism)

⭐⭐ OOP dilleri için 7 tasarım sorusu

Bölümün iskeleti. Aşağıdaki her dil bölümü, bu yedi soruya verilen farklı cevaplar olarak okunmalı.

1 · Exclusivity of objects — üç yaklaşım

2 · Subclass'lar subtype mıdır? — ⭐ en olası karşılaştırma sorusu

3 · Single vs multiple inheritance

4 · Nesnelerin allocation ve deallocation'ı

5 · Dynamic vs static binding · 6 · Nested classes · 7 · Initialization

Dil örneği: Smalltalk — saf OOP

Dil örneği: C++ — hibrit

class base_class {
  private:   int a;  float x;      // hiçbir yerde görünmez
  protected: int b;  float y;
  public:    int c;  float z;
};

class subclass_1 : public  base_class { … };
//  b ve y → protected;  c ve z → public

class subclass_2 : private base_class { … };
//  b, y, c, z → HEPSİ private
//  hiçbir türetilmiş sınıf base_class'ın hiçbir üyesine erişemez

class subclass_3 : private base_class {
      base_class :: c;     // c yeniden dışa açılıyor
      …
}

class Thread { ... }
class Drawing { ... }
class DrawThread : public Thread, public Drawing { … }

class BC { protected: int x; }
class D1: public BC { … }        // yol 1
class D2: public BC { … }        // yol 2
class Z : public D1, public D2 { … }   //  x İKİ KEZ gelir  ✗

// ÇÖZÜM: virtual inheritance
class D1: public virtual BC { … }
class D2: public virtual BC { … }
class Z : public D1, public D2 { … }   //  x BİR KEZ gelir  ✓

class Shape     { public: virtual void draw() = 0; ... };   // abstract
class Circle    : public Shape     { public: void draw() { ... } ... };
class Rectangle : public Shape     { public: void draw() { ... } ... };
class Square    : public Rectangle { public: void draw() { ... } ... };

Square*    sq   = new Square;
Rectangle* rect = new Rectangle;
Shape*     ptr_shape;
ptr_shape = sq;        // bir Square'i gösteriyor
ptr_shape->draw();     // DİNAMİK bağlanır → Square::draw
rect->draw();          // STATİK bağlanır  → Rectangle::draw

// STACK'ten
Square sq;  Rectangle rect;
rect = sq;        // Square'in VERİ ÜYELERİ kopyalanır (object slicing!)
rect.draw();      // → Rectangle::draw  çağrılır

// HEAP'ten
Square    *sq   = new Square;
Rectangle *rect = new Rectangle;
rect = sq;        // POINTER ataması
rect->draw();     // → Square::draw  çağrılır

Dil örneği: Java

Slayt bu bölümü açıkça "C++'tan farklar" üzerinden kuruyor — sınav sorusu da büyük olasılıkla bu eksende gelir.

public interface Comparable <T> {
    public int comparedTo (T b);
}

// STATIC nested: dış sınıfın örneğine GEREK YOK
class Foo   { static class Bar { } }
class Driver{ Foo.Bar b = new Foo.Bar(); }

// NON-STATIC (inner): önce dış sınıf örneklenmeli
class Foo   { class Bar { } }
class Driver{ Foo i = new Foo();
              Foo.Bar b = i.new Bar(); }

Dil örneği: C#

public class Shape     { public virtual  void Draw() { . . . } }
public class Circle    : Shape     { public override void Draw() { . . . } }
public class Rectangle : Shape     { public override void Draw() { . . . } }
public class Square    : Rectangle { public override void Draw() { . . . } }

Nested classes: Doğrudan nested edilen bir C# sınıfı, Java'nın static nested class'ı gibi davranır; C# Java'nın non-static (inner) sınıfları gibi davranan nested sınıfları desteklemez.

Evaluation: C#, görece yeni tasarlanmış C-tabanlı bir OO dildir; C# ile Java'nın OOP desteği arasındaki farklar görece küçüktür.

Dil örneği: Ruby — saf OOP, ama farklı

⭐ OO yapıların gerçeklenmesi — CIR ve vtable

Instance data storage — Class Instance Record (CIR)

Hocanın bağlantısı: C++'ta sınıflar C'nin record (struct) yapısının uzantısı olarak tanımlanır — bu yüzden instance değişkenlerinin depolanması bir record gibi görünür ve öyle de gerçeklenir. Bu, Lecture #5'teki record erişimi ile birebir aynı mantıktır.

⭐ Dynamic binding'in gerçeklenmesi — vtable

public class A {
     public int a, b;
     public void draw()  { . . . }
     public int  area()  { . . . }
}
public class B extends A {
     public int c, d;
     public void draw()  { . . . }   // override
     public void sift()  { . . . }   // yeni
}

Final Deneme Sınavı

Hocanın teyit ettiği formatta (10–15 çoktan seçmeli + 3–5 açık uçlu), final kapsamından (Ch.6–12) — gerçek sınavdan geniş tutuldu ki daha çok konu taransın. Önce kendin çöz, sonra cevabı aç. Her cevabın altında kaynağı yazıyor.

Bölüm A — Çoktan seçmeli

int a = 5;
int fun1() { a = 17; return 3; }
…
a = a + fun1();