Soru:

"Bir programlama dilinin belirli özellikleri, içine kod yazılmasının tek yolunun yorumlanması gerekmesini gerektirebilir. Diğer bir deyişle, geleneksel bir CPU'nun yerel bir makine koduna derlemek mümkün değildir. Bu özellikler nelerdir?"

Derleyiciler: Parag H. Dave ve Himanshu B. Dave İlkeleri ve Uygulaması (2 Mayıs 2012)

Kitap cevap hakkında hiçbir ipucu vermiyor. Programlama Dilleri Kavramları (SEBESTA) konusuna cevap bulmaya çalıştım, ama boşuna. Web aramaları da çok az yararlandı. Herhangi bir fikrin var mı?

Yorumlanmış ve derlenmiş kod arasındaki fark, Raphael'in yorumunda vurgulandığı gibi, muhtemelen bir kurgudur :

the claim seems to be trivially wrong without further assumptions: if there is
an interpreter, I can always bundle interpreter and code in one executable ...

Gerçek şu ki, kod her zaman, yazılım, donanım veya her ikisinin bir kombinasyonu olarak yorumlanır ve derleme işlemi, hangisinin olacağını söyleyemez.

Derleme olarak algıladığınız şey, bir dil (kaynak için) başka bir T diline (hedef için) çeviri işlemidir . Ve, S tercümanı genellikle T tercümanından farklıdır .$S$$T$$S$$T$

Derlenmiş programı bir sentaks formu çevrilir başka sözdizimsel formuna P T , öyle ki dil amaçlanan semantik verilen S ve T , U S ve P , T bir kaç şey kadar, aynı hesaplama davranışı olduğunu sen genellikle karmaşıklık veya basit verimlilik (zaman, alan, yüzey, enerji tüketimi) gibi optimize etmek için değişmeye çalışıyorlar. Kesin tanımlamalar gerektireceği için fonksiyonel denklikten bahsetmemeye çalışıyorum.$P_S$$P_T$$S$$T$$P_S$$P_T$

Bazı derleyiciler aslında yürütmeyi "iyileştirmek" için değil, yalnızca kodun boyutunu azaltmak için kullanılmıştır. Platon sisteminde kullanılan dil için durum buydu (derleme olarak adlandırmasalar bile).

Derleme işleminden sonra tercümanına artık ihtiyaç duymuyorsanız, kodunuzun tamamen derlenmiş olduğunu düşünebilirsiniz . En azından, teorik sorudan ziyade bir mühendislik olarak sorunuzu okuyabilmemin tek yolu budur (teorik olarak tercümanı her zaman yeniden kurabilirim).$S$

Problem yaratabilecek bir şey, afaik, meta-daireselliktir . Bu, bir programın sözdizimsel yapıları kendi kaynak dili manipüle edeceği ve daha sonra orijinal programın bir parçası olmuş gibi algılanan bir program parçası yaratacağı zamandır. Eğer dil keyfi programı parçalarını üretebilir yana S anlamsız sözdizimsel parçaları manipüle keyfi hesaplama sonucunda, sana (bakış bir mühendislik açısından) neredeyse imkansız hale getirebilir dil haline programı derlemek tahmin ediyorum T , böylece şimdi T'nin fragmanlarını oluşturur . Bu nedenle için yorumlayıcı S ihtiyaç duyulabilir veya en az derleyici olacak S için$S$$S$$T$$T$$S$$S$S ' de üretilen parçalarınanında derlenmesiiçin T (ayrıcabu belgeye bakın).$T$$S$

Ancak bunun nasıl doğru bir şekilde formüle edilebileceğinden emin değilim (ve şu anda bunun için zamanım yok). Ve imkansız , resmileşmemiş bir mesele için büyük bir kelimedir.

Diğer açıklamalar

36 saat sonra eklendi. Bu çok uzun devam filmi atlamak isteyebilirsiniz.

Bu soruya yapılan birçok yorum, sorunun iki görüşünü gösterir: onu anlamsız gören teorik bir bakış açısı ve ne yazık ki kolay kolay şekillendirilemeyen bir mühendislik görüşü.

Yorumlama ve derlemeye bakmanın birçok yolu var ve birkaç tane çizmeye çalışacağım. Yönetebildiğim kadar gayrı resmi olmaya çalışacağım

Mezar taşı diyagramı

İlk formalizasyonlardan biri (1960'ların başından 1990'ların sonlarına kadar) T veya Tombstone diyagramlarıdır . Bu şemalar, beste edilebilir grafiksel unsurlarda, tercüman veya derleyicinin uygulama dili, yorumlanan veya derlenen kaynak dil ve derleyiciler için hedef dil olarak sunulmuştur. Daha ayrıntılı sürümler özellik ekleyebilir. Bu grafiksel gösterimler aksiyomlar, çıkarım kuralları olarak görülebilir, mekanik olarak üretim sürecini aksiyomlardan, Curry la Curry-Howard'dan geldiğinin bir kanıtı olarak mekanik olarak elde etmek için kullanılabilir.

Kısmi değerlendirme

Bir başka ilginç görüş kısmi değerlendirme paradigmasıdır. Bazı girdi verileri verilen yanıtları hesaplayan bir tür işlev uygulaması olarak programları basit bir şekilde görüyorum. Sonra bir tercüman dil için S bir program almak bir programdır p S yazılmış S ve veri d o programın, ve semantik göre sonuca hesaplar S . Kısmi değerlendirme iki bağımsız değişken bir programı uzmanlaşmış bir tekniktir bir 1 ve bir 2 , tek argüman, demek bir $I_S$$S$$p_S$$S$$d$$S$$a_1$$a_2$$a_1$, bilinen. Nihai olarak ikinci argümanı aldığınızda daha hızlı bir değerlendirme yapmaktır . Eğer özellikle yararlıdır bir 2 daha sık değişen bir 1 kısmi değerlendirme maliyeti olarak bir 1 , sadece tüm hesaplamaları itfa edilebilir bir 2 değişiyor.$a_2$$a_2$$a_1$$a_1$$a_2$

Bu, algoritma tasarımında sık sık görülen bir durumdur (genellikle SE-CS'deki ilk yorumun konusu), verilerin daha statik bir kısmı önceden işlendiğinde, ön işleme maliyetinin tüm uygulamalarda itfa edilebildiği durumlarda algoritmasının, giriş verilerinin daha değişken bölümleriyle birlikte.

Bu aynı zamanda tercümanların durumudur, çünkü ilk argüman yürütülecek programdır ve genellikle farklı verilerle birçok kez çalıştırılır (veya alt bölümleri farklı verilerle birçok kez çalıştırılır). Bu nedenle, belirli bir programın daha hızlı değerlendirilmesi için, bu program üzerinde kısmen argüman olarak değerlendirilerek bir tercümanın uzmanlaşması doğal bir fikir haline geldi. Bu, programı derlemenin bir yolu olarak görülebilir ve bir tercümanın ilk (program) argümanında kısmi olarak değerlendirilmesiyle derlenmesi üzerine önemli araştırmalar yapılmıştır.

Smn teoremi

Kısmi değerlendirme yaklaşımının güzel yanı, özellikle Kleene'in Smn teoreminde teorik olarak (teorik bir yalancı olabilir) köklerini çekmesidir . Burada, teorisyenleri rahatsız etmeyeceğini umarak sezgisel bir sunum yapmaya çalışıyorum.

Bir Gödel numaralandırma Verilen özyinelemeli fonksiyonlar görüntüleyebilir cp o Gödel sayısı göz önüne alındığında, böylece donanım olarak p (okuma nesne kodu bir programı) φ p tarafından tanımlanan işlevi olan p donanımınız üzerinde nesne koduyla bilgisayarlı (yani ).$\varphi$$\varphi$$p$$\varphi_p$$p$

En basit şekliyle, teorem wikipedia'da şöyle ifade edilir (gösterimdeki küçük bir değişikliğe kadar):

Bir Gödel numaralandırması alındığında yinelemeli fonksiyonları, ilkel özyinelemeli işlevi yoktur σ aşağıdaki özellikleri olan iki bağımsız değişken: Her Gödel'in numarası için q kısmi hesaplanabilir fonksiyonu f iki bağımsız olan, ifadeler φ σ ( q , x ) ( y ) ve f ( x , y ) , x ve y sayılarının aynı doğal kombinasyonları için tanımlanmıştır ve değerleri, bu tür bir kombinasyon için eşittir. Başka bir deyişle, aşağıdaki fonksiyonların genişletilebilir eşitliği her şey için geçerlidir.$\varphi$$\sigma$$q$$f$$\varphi_{\sigma(q,x)}(y)$$f(x,y)$$x$$y$ : $x$$\;\;\varphi_{\sigma(q,x)} \simeq \lambda y.\varphi_q(x,y).\,$

Şimdi, alma tercüman olarak I S , x bir program kaynağı kodu olarak p S ve Y veri olarak d , bu program için, yazabiliriz: $q$$I_S$$x$$p_S$$y$$d$$\;\;\varphi_{\sigma(I_S,p_S)} \simeq \lambda d.\varphi_{I_S}(p_S,d).\,$

tercüman yürütülmesi olarak görülebilir Ben S dil ile yazılmış programları yorumlamak için hazır bir kara kutu olarak, yani donanım üzerinde S .$\varphi_{I_S}$$I_S$$S$

Fonksiyon tercüman uzmanlaşmış bir fonksiyonu olarak görülebilir I S programı için P , S , kısmi değerlendirmede olduğu gibi,. Böylece Gödel'in numarası σ ( I S , p S ) görülebilir programı derlenmiş versiyonu nesne kodu vardır s S .$\sigma$$I_S$$P_S$$\sigma(I_S,p_S)$$p_S$

Yani fonksiyonu argüman olarak bir program kaynak kodunu almak bir fonksiyonu olarak görülebilir q S dili ile yazılmış S , ve bu program için nesne kodu sürümünü döndürür. Yani C S genellikle denen şeydir bir derleyici.$\;C_S = \lambda q_S.\sigma((I_S,q_S)$$q_S$$S$$C_S$

Bazı sonuçlar

Ancak dediğim gibi: "teori bir yalancı olabilir" veya aslında biri gibi görünüyor. Sorun, fonksiyonundan hiçbir şey bilmememizdir . Aslında bu tür birçok fonksiyon var ve benim tahminim teorem kanıtının, Raphael'in önerdiği çözümden ziyade, bir mühendislik bakış açısından daha iyi olmayabilecek çok basit bir tanım kullanabileceğidir: kaynak kodu q S tercüman ile ben S . Bu her zaman yapılabilir, şöyle diyebiliriz: derleme her zaman mümkündür.$\sigma$$q_S$$I_S$

Bir derleyicinin ne olduğuna dair daha kısıtlayıcı bir fikir oluşturmak, daha ince bir teorik yaklaşım gerektirecektir. Bu yönde ne yapılmış olabileceğini bilmiyorum. Kısmi değerlendirmede yapılan çok gerçek iş, mühendislik açısından daha gerçekçidir. Ve elbette, Curry-Howard izomorfizmine dayanarak, tip teorisi bağlamında geliştirilen programların kendi özelliklerinin kanıtından çıkarılması da dahil olmak üzere, derleyiciler yazmak için başka teknikler de var (ancak uzmanlık alanımın dışına çıkıyorum). .

Buradaki amacım Raphael'in sözlerinin "çılgın" olmadığını, her şeyin açık olmadığını ve hatta basit olmadığını hatırlatmaktı. Bir şeyin imkansız olduğunu söylemek, sadece nasıl ve neden imkansız olduğuna dair kesin bir anlayışa sahip olması durumunda, kesin tanımlar ve bir kanıt gerektiren güçlü bir ifadedir . Ancak böyle bir kanıtı ifade etmek için uygun bir formalizasyon oluşturmak oldukça zor olabilir.

Bu, belirli bir özellik uyuşmasa bile, mühendisler tarafından anlaşılan anlamda, Gilles'un cevabında da belirtildiği gibi, böyle bir özelliği kullanmayan programların bölümlerine standart derleme teknikleri her zaman uygulanabilir.

Gilles'un anahtarını takip etmek için, dile bağlı olarak, derleme zamanında bazı şeylerin yapılabileceği, diğerlerinin çalışma zamanında yapılması gerektiği, bu nedenle de özel kod gerektiren bir derleme kavramının gerçekte olduğunu görebilirsiniz. yanlış tanımlanmış ve muhtemelen herhangi bir tatmin edici şekilde tanımlanamaz. Derleme, bazı algoritmalarda statik veri ön işleme ile karşılaştırdığımda, kısmi değerlendirme bölümünde göstermeye çalıştığım gibi, sadece bir optimizasyon işlemidir .

Karmaşık bir optimizasyon işlemi olarak, derleme kavramı aslında bir sürekliliğe aittir. Dilin veya programın özelliğine bağlı olarak, bazı bilgiler statik olarak bulunabilir ve daha iyi bir optimizasyona izin verebilir. Diğer şeylerin çalışma süresine ertelenmesi gerekir. İşler gerçekten kötüye gittiğinde, her şey çalışma zamanında en azından programın bazı kısımları için yapılmak zorundadır ve kaynak kodunu tercümanla birlikte paketlemek için yapabileceğiniz tek şey budur. Dolayısıyla bu donatma, bu derleme sürekliliğinin sadece en düşük noktasıdır. Derleyicilerle ilgili araştırmaların çoğu, dinamik olarak yapılması gerekenleri statik olarak yapmanın yollarını bulmakla ilgilidir. Derleme zamanı çöp toplama iyi bir örnek görünüyor.

Derleme işleminin makine kodu üretmesi gerektiğini söylemenin yardımı olmadığını unutmayın. Bu tam olarak yorumlayıcının makine kodu olduğu için paketlemenin yapabileceği şeydir (şey, çapraz derlemeyle biraz daha karmaşık hale gelebilir).

Asıl soru, derlemenin imkansız olmasıyla ilgili değil . Eğer bir dil yorumlanabilirse¹, o zaman tercümanı kaynak koduyla paketleyerek önemsiz bir şekilde derlenebilir. Soru, hangi dil özelliklerinin bunu esasen tek yol haline getirdiğini sormak.

Tercüman, kaynak kodunu girdi olarak alan ve bu kaynak kodun anlamıyla belirtilen şekilde davranan bir programdır. Bir tercüman gerekliyse, bu dilin kaynak kodunu yorumlamanın bir yolunu içerdiği anlamına gelir. Bu özelliğe denir eval. Dilin çalışma zamanı ortamının bir parçası olarak bir tercüman gerekliyse, dilin içerdiği anlamına gelir eval: ya evalilkel olarak var veya bir şekilde kodlanabilir. Betik dili olarak bilinen diller evalçoğu Lisp lehçesinde olduğu gibi genellikle bir özellik içerir .

Sadece bir dilin evalbulunması onun büyük kısmının yerel koda göre derlenemeyeceği anlamına gelmez. Örneğin, iyi yerel kod üreten ve yine de destekleyen Lisp derleyicileri optimize edilmiştir eval; evaled kodu yorumlanabilir veya anında derlenebilir.

evalnihai tercüman ihtiyacı olan bir özelliktir, ancak tercümandan daha kısa bir şey gerektiren başka özellikler de vardır. Derleyicinin bazı tipik aşamalarını göz önünde bulundurun:

1. ayrıştırma
2. Kontrol türü
3. Kod üretimi
4. bağlayıcı

evaltüm bu aşamaların çalışma zamanında gerçekleştirilmesi gerektiği anlamına gelir. Yerel derlemeyi zorlaştıran başka özellikler de var. En alttan ele alarak, bazı diller, işlevlerin (yöntem, prosedür vb.) Ve değişkenlerin (nesneler, referanslar, vb.) Yerel olmayan kod değişikliklerine bağlı olabileceği yollar sağlayarak geç bağlantı kurulmasını teşvik eder. Bu, verimli yerel kod oluşturmayı zorlaştırır (ancak imkansız değildir): nesne referanslarını sanal bir makinede aramalar olarak tutmak daha kolaydır ve VM motorunun bağlantıdaki bağlantıları ele almasına izin verin.

Genel olarak konuşursak, yansıma dilleri yerel yasaya göre derlemeyi zorlaştırır. Bir değerlendirme ilkeli, aşırı bir yansıma örneğidir; birçok dil o kadar ileri gitmez, ancak yine de bir sanal makine için tanımlanmış bir anlambilimine sahiptir, örneğin kodun bir sınıfa isim vermesini, kalıtımını kontrol etmesini, yöntemlerini listelemesini, bir yöntemi çağırmasını vb. sağlar. JVM ile Java ve C # ile .NET iki ünlü örnekleridir. Bu dilleri uygulamanın en basit yolu onları bytecode ile derlemektir , ancak yine de , en azından gelişmiş yansıma olanakları kullanmayan en az program parçalarını derleyen yerel derleyiciler (çoğu zaman tam zamanında ) vardır.

Tip kontrolü, bir programın geçerli olup olmadığını belirler. Farklı diller, çalışma zamanına göre derleme zamanında ne kadar analiz yapıldığına ilişkin farklı standartlara sahiptir: bir dil, kodu çalıştırmaya başlamadan önce birçok kontrol gerçekleştirirse “statik olarak yazılmış” ve kodu çalıştırmadan önce “dinamik olarak yazılmış” olarak bilinir. Bazı diller dinamik bir döküm özelliği veya marşal ve yazım denetimi özelliği içerir; Bu özellik çalışma zamanı ortamında bir typechecker katıştırmayı gerektirir. Bu, çalışma zamanı ortamında bir kod oluşturucu veya tercüman dahil etme gereksinimlerine diktir.

¹ _{Alıştırma: yorumlanamayan bir dil tanımlayın.}

Bence yazarlar derlemenin demek olduğunu varsayıyorlar.

• kaynak programın çalışma zamanında bulunması gerekmez ve
• çalışma zamanında derleyici veya tercüman bulunması gerekmez.

İşte böyle bir şema için “imkansız” olmasaydı problemli hale getirecek bazı örnek özellikler:

1. Bir değişkenin çalışma zamanındaki değerini, değişkene adını (bir dize olan) göre bakarak sorgulayabilirseniz, değişken adlarının çalışma zamanında etrafında olması gerekir.

2. Çalışma zamanında bir işlevi / yordamı arayabilirseniz, adını (bir dize olan) ona bakarak, çalışma zamanında işlev / yordam adlarına ihtiyacınız olacaktır.

3. Çalışma zamanında (bir dize olarak) bir program parçası oluşturabilir, başka bir program çalıştırarak veya bir ağ bağlantısından vb. Okuyarak söyleyebilirseniz, çalışma zamanında bir tercümana veya derleyiciye ihtiyacınız olacaktır. bu program parçasını çalıştırın.

Lisp üç özelliğe sahiptir. Bu yüzden, Lisp sistemleri her zaman çalışma zamanında yüklenen bir tercümana sahiptir. Diller Java ve C #, çalışma zamanında kullanılabilir işlev adlarına ve ne anlama geldiklerini görmek için tablolara sahiptir. Muhtemelen Basic ve Python gibi diller çalışma zamanında değişken isimlerine de sahiptir. (Bundan% 100 emin değilim).

Mevcut cevapların ifadeyi / cevapları "fazla düşünmesi" mümkündür. muhtemelen yazarların kastettiği şey şu fenomendir. birçok dilde "eval" benzeri bir komut vardır; örneğin, javascript değerlendirmesine bakın ve davranışı genellikle CS teorisinin özel bir parçası olarak incelenir (örneğin, Lisp). Bu komutun işlevi dize dil tanımı bağlamında değerlendirmektir. bu nedenle, "yerleşik derleyici" ile benzerlik göstermektedir. derleyici, çalışma zamanına kadar dizenin içeriğini bilemez. bu nedenle, değerlendirme sonucunu makine kodunda derlemek derleme zamanında mümkün değildir.

diğer cevaplar, yorumlanmış veya derlenmiş diller arasındaki ayrımın, birçok durumda özellikle Java gibi "tam zamanında derleyici" aka "Hotspot" (javascript motorları, örneğin V8, bu aynı tekniği kullanmaktadır) gibi daha modern dillerle belirgin bir şekilde bulanıklaştırabileceğine işaret etmektedir . "eval benzeri" işlevsellik kesinlikle onlardan biri.

LISP, "gerçek" bir dilin temeli olarak bir çeşit üst düzey "makine" dili olarak algılandığından berbat bir örnektir. Adı geçen "gerçek" dil asla gerçekleşmedi. LISP makineleri, donanımda LISP (çoğu) yapılması fikri üzerine inşa edilmiştir. Bir LISP tercümanı sadece bir program olduğundan, prensip olarak devrede uygulanması mümkündür. Belki pratik değil; ama imkansız olmaktan uzak.

Ayrıca, normalde "CPU" adı verilen silikonda programlanan birçok tercüman vardır. Ve genellikle makine kodlarını yorumlamak (henüz mevcut değil, eldeki değil ...) yararlıdır. Örneğin, Linux'un x86_64 ilk kez emülatörlere yazıldı ve test edildi. Talaşlar piyasaya girdiğinde, sadece erken evlatçılar / testçiler için bile tam dağıtımlar yapıldı. Java genellikle silikon yazması zor olmayan bir tercüman olan JVM koduna derlenir.

Çoğu "yorumlanmış" dil, optimize edilmiş ve sonra yorumlanmış bir iç formda derlenir. Bu, örneğin Perl ve Python'un yaptığıdır. Unix kabuğu gibi yorumlanacak diller için derleyiciler de vardır. Diğer taraftan, geleneksel olarak derlenmiş dilleri yorumlamak mümkündür. Gördüğümü bir miktar aşırı bir örnek kullanılan bir editör yorumlanır uzantı dili C. C normal, ancak basit, programlar sorunsuz çalışabilir.

Öte yandan, modern CPU'lar "makine dili" girdisini bile alır ve daha sonra yürütülmesi için dağıtılmadan önce yeniden düzenlenir ve optimize edilir (yani "derlenir").

Tüm bu "derleyici" - "tercüman" ayrımı oldukça fazladır, yığında bir yerde "kod" alan ve "doğrudan" uygulayan nihai bir tercüman vardır. Programlayıcıdan gelen girdi, "derleme" adı verilen ve sadece kumda rastgele bir çizgi çizen çizgi boyunca dönüşümler geçirir.

Gerçek şu ki, bazı Temel programları yorumlamak ve assembler'ı çalıştırmak arasında büyük bir fark var. Ve P-kodu ile / byte kodu arasında (tam zamanında) derleyicileri olan veya olmayan alanlar vardır. Bu yüzden bu gerçeğin bağlamında bazı noktaları özetlemeye çalışacağım.

• Kaynak kodunun nasıl ayrıştırılacağı çalışma zamanı koşullarına bağlıysa, derleyici yazmak imkansız olabilir veya kimsenin rahatsız etmeyeceği kadar zor olabilir.

• Kendini değiştiren kod genel durumda derlemek imkansızdır.

• Değerlendirme benzeri bir işlev kullanan bir program genellikle önceden derlenemez (programın bir parçası olarak kendisine verilen dizeyi görürseniz), yine de değerlendirilen kodu tekrar tekrar çalıştıracaksanız, yine de eval benzeri işlevinizin derleyiciyi çağırması için kullanışlıdır. Bazı diller, derleyicinin bunu kolaylaştırması için bir API sağlar.

• Nesneleri ismiyle gönderme yeteneği derlemeyi engellemez, ancak tablolara ihtiyacınız vardır (belirtildiği gibi). İşlevleri ada göre çağırmak (IDispatch gibi), çoğu insanın bir işlev çağrısı yorumlayıcısından etkili bir şekilde bahsettiğimizi kabul edeceğini düşündüğü noktaya kadar çok fazla su tesisatı gerektirir.

• Zayıf yazma (tanımınız ne olursa olsun) derlemeyi zorlaştırır ve belki de sonuçlar daha az verimli olur, ancak farklı değerler farklı ayrıştırmaları tetiklemedikçe, genellikle imkansız değildir. Burada kayan bir ölçek var: eğer derleyici asıl tipini çıkaramazsa, dallar, işlev çağrıları ya da böyle bir şey olmayacak şekilde yayması, yorumlayıcı bitlerini çalıştırılabilir dosyaya etkin bir şekilde yerleştirmesi gerekecektir.

Dil için bir derleyiciyi imkansız kılan bir programlama dilinin temel özelliğini (katı anlamda, aynı zamanda kendi kendini barındırma bölümüne bakınız ) kendi kendini değiştirme özelliği olduğunu varsayardım . Yani , dil çalışma sırasında kaynak kodunu değiştirmeye izin verir (sth derleyici üreten, sabit ve statik, nesne kodu yapamaz). Klasik bir örnek Lisp (bakınız ayrıca Homoiconicity ). Benzer işlevler, birçok dilde (örneğin javaScript) bulunan eval gibi bir dil yapısı kullanılarak sağlanır . Eval aslında çalışma sırasında tercümanı (işlev olarak) çağırır .

Başka bir deyişle, dil kendi meta sistemini temsil edebilir (ayrıca bakınız Metaprogramming )

Not o dil yansıma belli kaynak kodunun meta veriler hakkında sorgulama anlamında, ve muhtemelen yalnızca (Java'nın veya PHP'nin yansıma mekanizması gibi STH) 'dir meta verileri değiştirmek sorunlu değil zaten o sahip olduğundan, bir derleyici Derleme zamanında meta-veri ve gerektiğinde derlenmiş program için onları kullanılabilir hale getirebilir.

Derlemeyi zorlaştıran ya da en iyi seçenek yapmayan başka bir özellik (ancak imkansız değil), dilde kullanılan yazma düzenidir (yani dinamik yazma vs statik yazma ve güçlü yazma vs gevşek yazma). Bu, derleyicinin tüm semantiklere derleme zamanında sahip olmasını zorlaştırır, bu nedenle etkili bir şekilde derleyicinin bir kısmı (diğer bir deyişle bir tercüman), çalışma zamanında semantiği işleyen oluşturulan kodun bir parçası haline gelir . Başka bir deyişle, bu derleme değil, yorumlamadır .

Asıl sorunun iyi şekillenmediğini hissediyorum. Sorunun yazarları biraz daha farklı bir soru sormayı amaçlamış olabilir: Bir programın dilinin hangi özellikleri onun için derleyici yazmayı kolaylaştırır?

Örneğin, bağlamsız bir dil için bir derleyici yazmak, bağlam duyarlı bir dilden daha kolaydır. Bir dili tanımlayan dilbilgisi aynı zamanda belirsizlikler gibi derlenmeyi zorlaştıran sorunlara da sahip olabilir. Bu tür meseleler çözülebilir fakat ilave çaba gerektirmektedir. Benzer şekilde, sınırlandırılmamış dilbilgileri tarafından tanımlanan dillerin içeriğe duyarlı dillere göre ayrıştırılması daha zordur (bkz. Chomsky Hiyerarşisi ). Bildiğim kadarıyla, en yaygın şekilde kullanılan prosedürel programlama dilleri içeriğe yakın, ancak içeriğe duyarlı birkaç öğeye sahip ve bunları derlemelerini nispeten kolaylaştırıyor.

Sorunun doğru bir cevabı var, o kadar açık ki, genellikle önemsiz olduğu göz ardı ediliyor. Ancak birçok bağlamda önemi var ve yorumlanan dillerin var olmasının temel nedeni:

Kaynak kodunuz henüz yoksa , kaynak kodun makine kodunda derlenmesi imkansızdır .

Tercümanlar esneklik ekler ve özellikle de temel proje derlendiğinde mevcut olmayan kod çalıştırma esnekliğini eklerler.