|
Derleyici Tasarımı
|
Şimdiye kadar neler yaptığımızı örnek metin üzerinden özet geçelim:
Girdi metnimizi önce lexeme denen metin parçalarına bölmüştük, sonrasında tokenizer'dan geçirerek sadeleştirmiştik. Identifier'lara da sayısal ID'ler atayarak char * tutma zahmetinden kurtulmuştuk, ayrıca aynı identifier'a aynı sayısal ID'yi atamak için bir ident_map oluşturmuştuk.
Parsing'e başlamadan önce formal gramerlere değineceğiz. Derleyici Front End'i sayfasında gördüğümüz ağaçları hatırlayalım:
1 + 3 / ((2 + 1) * 4³)
|
if (x == -1) y = 2 + func();
|
Bu ağaçlara, yazılım dilinin gramerinden ziyade anlamını içermesinden ötürü abstract syntax tree (AST) deniyor. Parser ile elde edeceğimiz ağaçlar, concrete syntax tree (CST) denen daha "detaylı" yapılar olacak.
Bu CST'yi oluşturan gramer,
Gramer dedik demesine ancak bu yapı insan dillerinin gramerinden biraz farklı. Bu formal dillerin grameridir, context free grammar (CFG) olarak adlandırılır. Formal dillerin gramer sınıflarına değinmeyeceğiz, yazılım dilimizi CFG olarak tanımayacağız.
Formal dillere niçin gramer dediğimizi biraz somutlaştıralım. Türkçenin basit bir formunu formal dil olarak tanımlayalım ve gramer olarak hatasız "Formal dilleri öğreniyorum." cümlesini irdeleyelim:
Aynı cümledeki kelimeleri türden kelimelerle değiştirdik ve tekrardan gramer yapısı olarak "doğru" bir cümle edindik.
⟨Sıfat⟩ veya ⟨SıfatTamlaması⟩ gibi, cümlenin yapısını tanımlayan ve başka kurallarla daha alt parçalara genişletilebilen yapısal kategorilerdir.⟨SıfatTamlaması⟩ → ⟨Sıfat⟩ ⟨İsim⟩ satırında olduğu gibi, bir nonterminal'in hangi öğelere (terminal veya nonterminal) dönüşebileceğini tanımlayan kuralların her birine denir.Şimdi bu nonterminal, token ve production rules'tan tree oluşturacak sistematik bir yapıya ihtiyacımız var: Top-Down Parsing
Alt sayfalar