Neden kaynak kodunun yerine sözdizimi ağacını saklamıyoruz?

Çok fazla programlama dilimiz var. Her dil ayrıştırılır ve kod yazılmadan önce sözdizimi kontrol edilir, böylece soyut bir sözdizimi ağacı (AST) oluşturulur.

Bu soyut sözdizim ağacımız var, neden bu sözdizimi ağacını kaynak kodu yerine (ya da kaynak kodunun yanında) saklamıyoruz?

Kaynak kod yerine bir AST kullanarak. Bir takımdaki her programcı bu ağacı istediği herhangi bir dile (uygun bağlamda serbest gramer ile) seri hale getirebilir ve bittiğinde AST'ye geri dönebilir. Bu, kodlama stili soruları hakkındaki tartışmayı ortadan kaldıracak ({ve} nereye, boşluk bırakacak, girintiyi vb. Nereye koyacağınız).

Bu yaklaşımın artıları ve eksileri nelerdir?

Boşluk ve Yorumlar

Genellikle bir AST boşluk, satır sonlandırıcılar ve yorumlar içermez.

Anlamlı Biçimlendirme

Çoğu durumda bunun pozitif (kutsal savaşları biçimlendirmeyi ortadan kaldırır) olduğu doğru, orijinal kodun biçimlendirilmesinin çok satırlı dizgenin değişmezleri ve "kod paragrafları" gibi bazı anlamlar taşıdığı durumlar var (blokları ayırarak) boş satırlı ifadeler).

Derlenemeyen kod

Birçok ayrıştırıcı eksik sözdizimine karşı çok dirençli olsa da, hatalı kod sık sık çok garip bir sözdizimi ağacına neden olur; bu da kullanıcının dosyayı yeniden yüklediği noktaya kadar ince ve karanlıktır. IDE'nizde bir hata yaptınız ve sonra aniden tüm dosyanın "dalgalı" olduğu oldu mu? Bunun başka bir dilde nasıl yükleneceğini hayal edin.

Belki kullanıcılar çözülemeyen bir kod vermezler, ancak kesinlikle yerel olarak kaydetmeleri gerekir.

İki dil mükemmel eşleşmiyor

Diğerlerinin de belirttiği gibi, mükemmel özellik paritesine sahip neredeyse iki dil yok. Düşünebileceğim en yakın VB ve C #, veya JavaScript ve CoffeeScript, ancak VB bile C # ile tam olarak eşdeğer olmayan XML Literals gibi özelliklere sahip ve JavaScript'ten CoffeeScript'e dönüşüm birçok JavaScript değişmezine neden olabilir.

Yazdığım bir yazılım uygulamasında, kullanıcıların arka planda JS'ye dönüştürülen "sade İngilizce" ifadelerini girmeleri beklendiği için bunu yapmamız gerekiyor. Yalnızca JS sürümünü saklamayı düşündük, ancak güvenilir bir şekilde yüklenen ve kaldırılan şekilde yapmak için neredeyse kabul edilebilir bir yol bulamadık, bu nedenle her zaman hem kullanıcı metnini hem de JS sürümünü ve "düz ingilizce" olarak belirtilen bir bayrağı sakladık. msgstr "sürüm tamamen ayrıştırılmış veya ayrılmamış.

Neden kaynak kodu yerine bu sözdizimi ağacını saklamıyoruz? Bir takımdaki her programcı bu ağacı herhangi bir dile serileştirebilir, istedikleri zaman bitirip AST'ye geri döndürebilirler.

Aslında, bu makul bir fikir. Microsoft’un 1990’larda neredeyse aynısını yapmak için bir araştırma projesi vardı .

Birkaç senaryo akla geliyor.

Birincisi oldukça önemsizdir; Dediğiniz gibi, AST'nin, boşluk bırakma ve benzeri şeyler için farklı programcıların tercihlerine bağlı olarak farklı görünümlerde sunulmasını sağlayabilirsiniz. Ancak, bir AST'yi depolamak bu senaryo için fazla önemlidir; Sadece kendine güzel bir yazıcı yaz. Editörünüze bir dosya yüklediğinizde, tercih ettiğiniz formata koymak için güzel yazıcıyı çalıştırın ve kaydettiğinizde tekrar orijinal formata dönün.

İkincisi daha ilginç. Soyut sözdizimi ağacını saklayabiliyorsanız, o zaman kod farklılaşması bir değişiklik metinsel değil, sözdizimsel hale gelir. Kodun taşındığı yeniden yapılanmaların anlaşılması çok daha kolay hale gelir. Tabii ki, ağaç dibi algoritmalarını yazmanın tamamen önemsiz olmadığı ve genellikle dil bazında yapılması gerektiği elbette. Metin fark hemen hemen her dil için çalışır.

Üçüncüsü, Simonyi'nin Kasıtlı Programlama için öngördüğü şeye benzer: programlama dillerinde ortak olan temel kavramların seri hale getirilmiş olması ve daha sonra farklı dillerde oluşturulan bu kavramların farklı görüşlerine sahip olmanız. Güzel bir fikir olsa da, çirkin gerçek, dillerin ayrıntılarında, en düşük ortak paydalı bir yaklaşımın gerçekten işe yaramadığından yeterince farklı olmasıdır.

Yani, kısacası, bu çok hoş bir fikir ama nispeten küçük bir fayda için muazzam miktarda ekstra iş. Bu yüzden pek kimse bunu yapmaz.

Bunun tam olarak bayt kodunun .NET'te olduğunu iddia edebilirsiniz. Infact redgate'in reflektör programı byte kodunu bir dizi .NET programlama diline çeviriyor.

Ancak, bazı sorunlar var. Sözdizimi, bir dilde temsil edebileceğiniz, diğer dillerde temsili olmayan şeyler olduğu sürece dile özgüdür. Bu, C ++ ile tüm 7 erişim seviyelerine erişimi olan tek .NET dili olan .NET'te gerçekleşir.

.NET ortamı dışında çok daha zor olur. Her dil daha sonra kendi kitaplıklarını oluşturmaya başlar. Simüler problemleri çok farklı şekillerde çözdüklerinde aynı talimatların uygulanmasını yansıtan hem C hem de Java dilinde genel bir sözdizimini yansıtmak mümkün olmazdı.

Fikrinizden bazılarını beğeniyorum, ancak dili diline çevirmenin ne kadar kolay olduğunu çok abartıyorsunuz. Bu kadar kolay olsaydı, AST'yi saklamanıza bile gerek kalmazdı, çünkü X dilini her zaman AST'ye ayrıştırırdınız, sonra AST'den Y'ye gidersiniz.

Ancak, derleyici özelliklerinin AST'nin bir kısmını bir tür API aracılığıyla gösterme konusunda biraz daha fazla düşünmesini diliyorum. En boy yönelimli programlama, yeniden düzenleme ve statik program analizi gibi şeyler, zaten bir derleyici yazarlar tarafından uygulanmakta olan çalışmaların çoğunu yinelemek zorunda olan bu yeteneklerin uygulayıcısı olmadan, böyle bir API ile uygulanabilir.

Programcının bir programı temsil etmek için veri yapısının dizeleri içeren bir sürü dosya gibi olması gariptir.

En belirgin noktaların şunlar olduğunu düşünüyorum:

• Avantaj yok. Herkesin evcil hayvan dilini kullanabileceği anlamına geldiğini söylediniz. Ancak bu doğru değil - bir sözdizimi ağacı gösterimi kullanmak yalnızca sözdizimsel olanları değil, sözdizimsel farklılıkları ortaya çıkarır. Çok benzer diller için bir ölçüde çalışır - böyle bir VB ve C # veya Java ve Scala. Ama tamamen orada bile değil.

• Sorunlu. Dil özgürlüğünü kazandınız, ancak araç özgürlüğünü kaybettiniz. Artık okumak ve bir metin editörü kod, hatta herhangi bir IDE düzenleyebilirsiniz - Eğer bağlı okuma ve kod düzenleme her ikisi için AST temsilini konuşan belirli bir araç üzerinde. Burada kazanılan hiçbir şey yok.

  Bu son noktayı göstermek için, güçlü bir BASIC lehçesinin tescilli bir uygulaması olan RealBasic'e bakın. Bir süre için, neredeyse dilin çıkarabileceği gibi görünüyordu, ancak tamamen satıcıya bağlıydı, yalnızca kendi IDE'sindeki kodu görebiliyordu, çünkü özel bir metin dışı formatta kaydedilmişti. Büyük hata.

Hem metni hem de AST'yi saklarsanız, o zaman gerçekten bir şey eklememişsinizdir, çünkü metin zaten bir dildedir ve AST, metinden hızla yeniden oluşturulabilir.

Öte yandan, yalnızca AST'yi depolarsanız, geri dönüşü olmayan yorumlar gibi şeyleri kaybedersiniz.

Bu fikrin teoride ilginç olduğuna inanıyorum, ancak farklı programlama dilleri, diğer dillerde eşdeğer olmayan farklı yapıları desteklediğinden çok pratik değil.

Örneğin, X ++ 'da, çok fazladan fazla kod olmadan (fazladan sınıflar, fazladan mantık vb.) C # ile yazılamayan bir' while select 'ifadesi vardır. http://msdn.microsoft.com/en-us/library/aa558063.aspx

Burada söylediğim şey, birçok dilin aynı dilin büyük kod bloklarına veya diğerlerinde hiç bulunmayan öğelere bile çeviren sözdizimsel şekere sahip olduğu. AST yaklaşımının işe yaramayacağına bir örnek:

X dili, 4 ifadesinde AST dilinde çevrilmiş bir K anahtar sözcüğüne sahiptir: S1, S2, S3 ve S4. AST şimdi Y diline çevrildi ve bir programcı S2'yi değiştirdi. Şimdi X’e yapılan çeviriyle ne olacak? Kod, tek bir anahtar kelime yerine 4 ifadeye çevrilmiş ...

AST yaklaşımına karşı son argüman platform işlevleridir: bir işlev platforma gömülü olduğunda ne olur? .NET'in Environment.GetEnvironmentVariable gibi. Nasıl çeviriyorsun?

Bu fikre dayanan bir sistem var: JetBrains MPS . Bir editör biraz tuhaf, ya da sadece farklı, ama genel olarak böyle büyük bir problem değil. Diğer editörler, - En büyük sorun normal metin tabanlı araçlarından herhangi kullanamaz yüzden, artık bir metin olmadığını, iyi olduğunu grep, sedbirleştirmek ve fark araçları, vb

Aslında, genellikle AST'leri depolayan ve editörlerinde AST'nin bir projeksiyonunu belirli bir dile geri döndüren "dil tezgahları" olarak bilinen birkaç ürün vardır. @ Sk-mantığın dediği gibi, JetBrains'in MPS'si böyle bir sistemdir. Bir diğeri, Kasıtlı Yazılımın Kasıtlı Çalışma Tezgahıdır.

Dil çalışma tezgahları için potansiyel, etki alanına özgü bir projeksiyon oluşturabileceğiniz için, özellikle etki alanına özgü diller alanında çok yüksektir. Örneğin, Kasıtlı, devre şeması olarak projelendirilen elektriğe ilişkin bir DSL gösterecektir - bir alan uzmanının konuşması ve eleştirmesi için metin tabanlı bir programlama dilinde açıklanan bir devreden çok daha kolay ve daha doğru.

Uygulamada, dil tezgahlarının anlaşılması yavaş olmuştur çünkü DSL çalışmasının yanı sıra geliştiriciler muhtemelen tanıdık, genel bir programlama dilinde çalışmayı tercih ederler. Bir metin editörü veya programlama IDE'si ile kafa kafaya karşılaştırıldığında, dil tezgahları tonlarca ek yüke sahiptir ve avantajları neredeyse net değildir. Gördüğüm dil çalışma tezgahlarının hiçbiri kendilerini kendi IDE'lerini kolayca uzatabilecekleri bir noktaya kadar zorlamadılar - yani, eğer çalışma tezgahları üretkenlik için harikaysa, neden çalışma tezgahı araçları daha iyi hale gelmedi? -ve daha hızlı ve daha hızlı fiyatlarda daha iyi?

Aklımı okuyordun.

Bir kaç yıl önce bir derleyici dersi aldığımda, bir AST alıp seri hale getirdiyseniz, normal infix notasyonu yerine önek notasyonu ile keşfetti ve tüm ifadeleri sınırlandırmak için parantez kullandığınızda Lisp elde ettiğinizi keşfettim. Lisans çalışmalarımda Scheme (Lisp lehçesi) hakkında bir şeyler öğrenmeme rağmen, bunun için hiçbir zaman takdir almadım. Bu kursun bir sonucu olarak Lisp ve lehçeleri için kesinlikle bir takdir kazandım.

Önerdiğiniz ile ilgili sorunlar:

1. Bir grafik ortamda AST oluşturmak zor / yavaş. Ne de olsa çoğumuz bir fareyi hareket ettirebileceğimizden daha hızlı yazabiliriz. Yine de, ortaya çıkan bir soru "program kodunu bir tabletle nasıl yazıyorsunuz?" Bir tablete yazmak, donanım klavyesine sahip bir klavyeye / dizüstü bilgisayara kıyasla daha yavaş / zahmetlidir. Bileşenleri bir paletteki büyük bir tuval üzerinde bir tuval üzerine sürükleyip bırakarak bir AST oluşturabilirseniz, tabletteki bir dokunmatik ekran cihaz programlaması gerçek bir şey olabilir.

2. Mevcut araçlarımızdan az / hiç biri bunu desteklememektedir. Giderek daha karmaşık IDE'ler ve gittikçe akıllı hale gelen editörler yaratma konusunda onlarca yıllık gelişimimiz var. Metni yeniden biçimlendirmek, metni karşılaştırmak, metin aramak için tüm bu araçlara sahibiz. Ağaçta normal ifade aramaya eşdeğer olabilecek araçlar nerededir? Ya da iki ağaç arasında bir fark? Bütün bunlar kolayca metinle yapılır. Fakat sadece kelimeleri karşılaştırabilirler. Değişken bir adı değiştirin, öyle ki kelimeler farklıdır, ancak anlamsal anlam aynıdır ve bu farklı araçlar sorunla karşılaşır. Metin yerine AST'ler üzerinde çalışmak üzere geliştirilen bu tür araçlar, anlamsal anlamın karşılaştırılmasında daha yakın olmanızı sağlar. Bu iyi bir şey olurdu.

3. Program kaynak kodunu bir AST'ye dönüştürmek nispeten iyi anlaşılırken (derleyiciler ve tercümanlarımız var, değil mi?), AST'yi program koduna dönüştürmek o kadar iyi anlaşılmamıştır. Büyük, bileşik bir sayı elde etmek için iki asal sayının çarpılması nispeten basittir ancak büyük, bileşik bir sayıyı asal sayılara geri döndürmek çok daha zordur; AST'leri ayrıştırma vs ayrıştırma ile buradayız. Dillerin arasındaki farklar bir sorun haline gelir. Belirli bir dilde bile, bir AST'yi ayrıştırmanın birçok yolu vardır. Örneğin, bir nesne koleksiyonunda yineleme ve bir tür sonuç elde etme. Bir dizi boyunca yineleme, bir for döngüsü kullanın? Bu kompakt ve hızlı olurdu, ancak sınırlamalar var. Bir çeşit yineleyici kullan, Koleksiyonda mı çalışıyorsunuz? Bu Koleksiyon değişken büyüklükte olabilir ve bu da (mümkün) hız pahasına esneklik katar. Harita indirgeme? Daha karmaşık, ancak örtük olarak paralelleştirilebilir. Ve bu sadece tercihlerinize bağlı olarak Java için.

Zamanla, geliştirme çabası harcanacak ve dokunmatik ekranları ve AST'leri kullanarak geliştireceğiz. Yazma bir gereklilikten daha az olacak. Nerede olduğumuza dair mantıklı bir ilerleme olarak görüyorum, bugün bilgisayarları nasıl kullandığımızı inceliyoruz.

Zaten ağaçlarla çalışıyoruz. Lisp yalnızca seri hale getirilmiş AST'ler. XML (ve HTML, uzantı olarak) yalnızca serileştirilmiş bir ağaçtır. Arama yapmak için zaten birkaç prototipimiz var: XPath ve CSS (sırasıyla XML ve HTML için). CSS tarzı seçiciler ve değiştiriciler oluşturmamızı sağlayan grafiksel araçlar oluşturulduğunda, # 2'nin bir kısmını çözmüş olacağız. Bu seçicilerin regex'leri destekleyecek şekilde genişletilebildiği durumlarda, daha yakın olacağız. İki XML veya HTML belgesini karşılaştırmak için hala iyi bir grafiksel fark aracı arıyorum. İnsanlar bu araçları geliştirdikçe, # 2 çözülebilir. İnsanlar zaten böyle şeyler üzerinde çalışıyor; Onlar henüz orada değiller.

Bu AST'leri programlama dili metnine koyabildiğimi görebilmemin tek yolu, hedef arayan bir şey olabilir. Var olan kodu değiştiriyorsam, hedef, değiştirilmiş kodumu başlangıç ​​koduna mümkün olduğunca benzer yapan bir algoritma ile gerçekleştirilebilir (minimum metinsel fark). Sıfırdan kod yazıyorsam, hedef en küçük, en dar kod olabilir (muhtemelen bir döngü için). Veya olabildiğince verimli bir şekilde paralelleştirilen kod olabilir (muhtemelen bir harita / küçültme veya CSP içeren bir şey). Dolayısıyla, aynı AST, hedeflerin nasıl belirlendiğine bağlı olarak aynı dilde bile önemli ölçüde farklı kodlara neden olabilir. Böyle bir sistemin geliştirilmesi # 3'ü çözecektir. Hesaplamalı olarak karmaşık olacaktı, bu da muhtemelen bir çeşit müşteri-sunucu düzenlemesine ihtiyacımız olacağını,

Amacınız, stilleri biçimlendirme hakkındaki tartışmayı ortadan kaldırmaksa, belki de istediğiniz şey bir kaynak dosyada okuyan, kişisel görüntüleme ve düzenleme tercihinize göre biçimlendiren, ancak kaydederken, seçilen stile göre biçimlenen bir editördür. kullanır.

Emacs gibi bir editör kullanıyorsanız oldukça kolaydır . Dosyanın tamamının biçimlendirme stilini değiştirmek üç komutlu bir iştir.

Ayrıca yükleme sırasında bir dosyayı otomatik olarak kendi tarzınıza dönüştürmek ve kaydederken onu takım stiline dönüştürmek için kancalar oluşturabilmelisiniz.

Kaynak kod yerine AST'yi okumak ve değiştirmek zordur.

Ancak, derleyici ile ilgili bazı araçlar AST kullanımına izin vermez. Java bytecode ve .NET Intermediate kodu bir AST'ye benzer şekilde çalışır.

güzel bir fikir; fakat her dilin AST'si diğerinden farklıdır.

Bildiğim tek istisna, microsoft'un "farklı sözdizimiyle aynı dil" olduklarını iddia ettiği VB.NET ve C # için. Diğer .NET dilleri (IronPython, F #, her neyse) bile AST düzeyinde farklıdır.

JVM dilleri ile aynı şey, hepsi aynı bytecode'u hedefliyor, ancak dil yapıları farklı, farklı diller ve farklı AST'ler yapıyor.

CoffeScript ve Xtend gibi 'ince katman' dilleri bile, altta yatan diller teorisinin çoğunu paylaşır (sırasıyla JavaScript ve Java); ancak AST düzeyinde tutulması gereken (ya da olması gereken) daha üst düzey kavramları tanıtın.

Eğer Xtend bir Java AST'den yeniden kurulabilirse, mevcut Java kodundan sihirli bir şekilde daha yüksek seviyelerde soyutlamalar yaratan bir Java'dan Xtend'e 'derleyici' olarak tanımlanacağını düşünüyorum.