Derleyici Derleyici Yazma - Kullanım ve Özellikler Hakkında Bilgi

Bu, dil tasarımında kullanılan kavramları bir çerçeve şeklinde soyutlamayı amaçlayan Soyutlama Projesi'nin kardeş projesine odaklanan bir dizi sorunun bir parçasıdır. Kardeş proje, maçlarda kod enjeksiyonu kullanılmadan dilbilgisi dosyalarından bir ayrıştırıcı oluşturmayı amaçlayan OILexer olarak adlandırılır.

Bu sorularla ilişkili, yapısal yazmayla ilgili diğer bazı sayfalar burada görülebilir ve kullanım kolaylığı burada bulunabilir . Çerçeve ve gönderilecek uygun yerle ilgili bir soruşturmayla ilişkili meta-konu burada bulunabilir .

Belirli bir dilbilgisinden ayrıştırma ağacını ayıklamaya başlamak üzere olduğum noktaya geliyorum, ardından ileri yolları (ANTLR 4'ün LL (*) benzeri) ayırt etmek için DFA kullanan bir Yinelenen İniş ayrıştırıcısı izliyorum. içgörü kazanmak için açacağımı düşündüm.

Ayrıştırıcı derleyicide ne tür özellikler idealdir?

Şimdiye kadar neler uygulandığına dair kısa bir genel bakış:

1. Şablonlar
2. Belirli bir noktada neyin geçerli olduğunu bilerek, ileriye bakın.
3. Değişmezleri kurallar dahilinde alarak ve hangi simgeden geldiklerine karar vererek 'Deliteralization' kuralını uygulayın.
4. Belirsiz Otomata
5. Deterministik Otomata
6. Jeton tanıma için basit sözcüksel durum makinesi
7. Jeton otomasyon yöntemleri:
   • Tara - yorumlar için yararlıdır: Yorum: = "/ *" Tara ("* /");
   • Çıkarma - Tanımlayıcılar için kullanışlıdır: Tanımlayıcı: = Çıkarma (IdentifierBody, Keywords);
     • Tanımlayıcının anahtar kelimeleri kabul etmediğinden emin olun.
   • Encode - Bir otomasyonu X serisi temel N geçiş sayısı olarak kodlar.
     • UnicodeEscape: = "\\ u" BaseEncode (IdentifierCharNoEscape, 16, 4);
       • Onaltılı 4 geçişli onaltılık bir unicode kaçış yapar. Bu ve: [0-9A-Fa-f] {4} arasındaki fark, Kodlama ile sonuçlanan otomasyonun, izin verilen onaltılık değerler kümesini IdentifierCharNoEscape kapsamıyla sınırlandırmasıdır. Bu yüzden \ u005c verirseniz, kodlama sürümü değeri kabul etmez. Bunun gibi şeylerin ciddi bir uyarısı var: Tutumlu kullanın. Ortaya çıkan otomasyon oldukça karmaşık olabilir.

Uygulanmayan şey CST üretimidir, bu çalışmayı elde etmek için Deterministik otomasyonları uygun bağlamı taşıyacak şekilde ayarlamam gerekir.

İlgilenenler için, T * y♯ projesinin orijinal formunun oldukça basılı bir resmini yükledim . Her dosya diğer her dosyaya bağlanmalı, onları takip etmek için bireysel kurallara bağlanmaya başladım, ancak çok uzun sürecekti (otomatikleştirmek daha kolay olurdu!)

Daha fazla içeriğe ihtiyaç duyulursa, lütfen buna göre gönderin.

Düzenleme 5-14-2013 : Belirli bir dilde durum makineleri için GraphViz grafikleri oluşturmak için kod yazdım. İşte AssemblyPart'ın bir GraphViz digrafisi . Dil açıklamasında bağlanan üyelerin göreli klasörlerinde bu kuralın digrafisi ile bir rulename.txt olmalıdır. Örneği yayınladığımdan beri bazı dil açıklamaları değişti, bunun nedeni gramerle ilgili şeyleri basitleştirmek. İşte ilginç bir grafik resmi .

Bu mükemmel bir soru.

Son zamanlarda birçok ayrıştırma üzerinde çalışıyorum ve IMHO bazı temel özellikler:

• Programlı bir API - ideal olarak sadece bir kütüphaneyi içe aktararak bir programlama dilinde kullanılabilir. GUI veya BNF benzeri bir arayüze de sahip olabilir, ancak programlı olan anahtardır, çünkü takımınızı, IDE'nizi, statik analizinizi, testinizi, dil soyutlama tesislerinizi, programcı aşinalık, dokümantasyon oluşturucuyu, oluşturma sürecini, Ayrıca, öğrenme eğrisini önemli ölçüde azaltan küçük ayrıştırıcılarla etkileşimli olarak oynayabilirsiniz. Bu nedenler onu "önemli özellikler" listemin en üstüne yerleştiriyor.

• @guysherman'ın belirttiği gibi hata raporlama Bir hata bulunduğunda, hatanın nerede olduğunu ve ne zaman meydana geldiğini bilmek istiyorum. Ne yazık ki, geri izleme devreye girdiğinde iyi hataların nasıl üretileceğini açıklamak için iyi kaynaklar bulamadım. (Not @ Sk-logic aşağıdaki yorum rağmen).

• kısmi sonuçlar. Ayrıştırma başarısız olduğunda, girdinin hatanın konumundan önce olan kısmından başarıyla ayrıştırıldığını görmek istiyorum.

• soyutlama. Asla yeterli fonksiyonda inşa edemezsiniz ve kullanıcının her zaman daha fazlasına ihtiyacı olacaktır, bu yüzden öndeki tüm olası fonksiyonları anlamaya çalışmak başarısızlığa mahkumdur. Şablonlarla kastettiğiniz bu mu?

• 2'nize katılıyorum (ileriye dönük tahmin). İyi hata raporları oluşturmaya yardımcı olduğunu düşünüyorum. Başka bir şey için yararlı mı?

• ayrıştırma gerçekleştiğinde bir ayrıştırma ağacı oluşturma desteği, belki de:

  • ağacın yapısının doğrudan dilbilgisine karşılık geldiği ve sonraki aşamaların hata raporlaması için düzen bilgisi içerdiği somut bir sözdizimi ağacı. Bu durumda, müşteri doğru ağaç yapısını elde etmek için hiçbir şey yapmak zorunda olmamalıdır - doğrudan dilbilgisine bağlı olmalıdır.
  • soyut bir sözdizimi ağacı. Bu durumda, kullanıcı tüm ayrıştırma ağaçlarıyla uğraşabilir

• bir tür günlük kaydı. Bundan emin değilim; ayrıştırıcının denediği kuralların bir izini göstermek ya da (örneğin) HTML belgeleri oluşturmak için belirteçleri kullanmak istemeniz durumunda, boşluk veya yorumlar gibi önemsiz belirteçleri takip etmek olabilir.

• bağlama duyarlı dillerle başa çıkma becerisi. Bunun ne kadar önemli olduğundan emin değilim - pratikte, bir dilin üst kümesini bağlamsız bir dilbilgisi ile ayrıştırmak, daha sonra ek geçişlerde içeriğe duyarlı kısıtlamaları kontrol etmek daha temiz görünüyor.

• özel hata mesajları, böylece belirli durumlarda hata raporlarını ayarlamak ve belki daha hızlı bir şekilde sorunları anlamak ve gidermek.

Öte yandan, hata düzeltmeyi özellikle önemli bulmuyorum - ancak şu anki ilerleme konusunda güncel değilim. Fark ettiğim problemler, araçların sağladığı olası düzeltmelerin: 1) çok sayıda ve 2) yapılan gerçek hatalara karşılık gelmediği ve bu kadar da yararlı olmadığıdır. İnşallah bu durum düzelecektir (veya belki de zaten böyle olmuştur).

Dil tasarımında deneyimli değilim, ancak bir oyun motoru için IDE oluştururken ve IDE yaparken bir kez ayrıştırıcı yazmaya başladım.

Nihai son kullanıcılarınız için önemli olan bir şey, bence, mantıklı olan hata mesajlarıdır. Biliyorum, özellikle dünyayı parçalayan bir nokta değil, geriye doğru takip ederek, bunun temel sonuçlarından biri yanlış pozitiflerden kaçınabilmeniz gerektiğidir. Sahte pozitifler nereden geliyor? Ayrıştırıcıdan ilk hataya düşerler ve asla tam olarak iyileşmezler. C / C ++ bununla ünlüdür (yeni derleyiciler biraz daha akıllı olsa da).

Bunun yerine neye ihtiyacınız var? Bir noktada neyin geçerli olduğunu / neyin geçerli olmadığını bilmek yerine, neyin geçerli olmadığını ve geçerli olmasını sağlamak için minimum bir değişiklik yapmayı bilmeniz gerektiğini, böylece ilgili yanlış hatalar oluşturmadan ayrışmaya devam edebileceğinizi düşünüyorum. özyinelemeli inişinizin karışmasına. Bu bilgileri üretebilen bir ayrıştırıcı oluşturabilmek sadece size çok sağlam bir ayrıştırıcı sağlamakla kalmaz, aynı zamanda ayrıştırıcıyı tüketen yazılım için bazı harika özellikler de açar.

Bu durumda gerçekten zor ya da aptalca açık bir şey önerebileceğimin farkındayım. Bu aradığınız şey değilse, cevabımı mutlu bir şekilde silerim.

Dilbilgisinin "özyinelemeli kural bırakma" gibi kısıtlamaları olmamalıdır. Günümüzde yaygın olarak kullanılan araçların buna sahip olması ve sadece yacc'yi doğru yaptıktan yaklaşık 50 yıl sonra sadece LL dilbilgisini emmeyi anlayabilmeleri saçma .

Doğru özyineleme için bir örnek (yacc sözdizimi kullanılarak):

list: 
      elem                  { $$ = singleton($1); }
    | elem ',' list         { $$ = cons($1, $2);  }
    ;

Sol özyineleme için bir örnek (yacc synatx kullanarak):

funapp:
    term                    { $$ = $1; }
    | funapp term           { $$ = application($1, $2); }
    ;

Şimdi, bu başka bir şeye "yeniden düzenlenmiş" olabilir, ancak her iki durumda da, belirli bir özyineleme türü, yalnızca "doğru" yoldur, çünkü işlev uygulaması özyinelemeli olarak (örnek dilde) listeler sağ özyinelemelidir. .

Gelişmiş araçlardan, her şeyi aracın yeniden empoze ettiği sol / sağ özyinelemeden "refactor" yapmasını istemek yerine, bir şeyler yazmak için doğal yolu desteklemelerini bekleyebilirsiniz.