Görsel programlama araçları, neden doğrudan AST ile çalışmıyorlar?

Blockly, friends ve Github'da barındırılan diğer projeler gibi birkaç açık kaynaklı görsel programlama aracı buldum, ancak doğrudan soyut sözdizimi ağacı ile çalışan herhangi bir şey bulamadım.

Neden?

Soruyorum, çünkü derleyici işleminde her derleyicinin bir AST'ye kaynak kodunu ayrıştırdığı bir aşama olduğunu öğrendiğimde, bazı görsel programlama araçlarının programlayıcıya yol vermek için bundan faydalanabileceği açıktı. AST'yi doğrudan görsel bir şekilde düzenlemek ve ayrıca kaynaktan düğüme-grafiğe gidiş dönüş yapmak ve daha sonra gerektiğinde tekrar kaynağa dönmek.

Örneğin, JavaScript AST Görüntüleyiciden gerçek bir JavaSript görsel programlama aracına kadar çok fazla bir fark olmadığını düşünebilirsiniz.

Peki neyi özlüyorum?

Bu araçların birçoğu do (daha doğrusu, bunun doğrudan bire-bir görselleştirme) soyut sözdizimi ağacı işi doğrudan. Yani gördüğüm Blockly, ve bunun gibi diğer blok tabanlı dilleri ve editörü içerir ( Çizilmeye , Kalem Kod / Damlacık , aksi! , GP , Karo Grace , vb).

Bu sistemler, başka bir yerde açıklanmış olan nedenlerden dolayı (uzay ve etkileşim zorluğu) geleneksel köşe ve kenar grafik gösterimi göstermez, ancak doğrudan bir ağacı temsil ederler. Bir düğüm veya blok, doğrudan fiziksel olarak ebeveyne dahilse, diğerinin çocuğudur.

Bu sistemlerden birini yaptım ( Çinili Grace , kağıt , kağıt ). Sizi temin ederim ki, doğrudan AST ile çalışıyor. Ekranda gördüğünüz, iç içe geçmiş DOM öğeleri (yani bir ağaç!) Olarak, sözdizimi ağacının tam bir temsilidir.

Bu, bazı kodların AST'sidir. Kök "... yapmak" için bir yöntem çağrısı düğümüdür. Bu düğümün iki çocuğu, "1" düğümü ve "10" düğümü olan "_ .. _" ile başlayan bazı çocukları vardır. Ekranda ortaya çıkan şey, tam olarak derleyicinin arka ucunun sürecin ortasında yaydığı şeydir - temelde sistemin çalışması.

İsterseniz, kenarları ekrandan size dönük (ve önlerindeki blok tarafından tıkanmış) işaret eden kenarlarıyla standart bir ağaç düzeni olarak düşünebilirsiniz, ancak yuvalama, bir ağacı tepe noktası olarak göstermenin geçerli bir yöntemidir. diyagram.

Aynı zamanda "kaynaktan düğüme-grafiğe gidiş dönüş yapacak ve daha sonra gerektiğinde tekrar kaynağa dönecektir". Aslında, bunun altındaki "Kod Görünümü" nü tıkladığınızda bunun olduğunu görebilirsiniz. Metni değiştirirseniz, yeniden ayrıştırılır ve ortaya çıkan ağaç yeniden düzenlenebilmeniz için oluşturulur ve blokları değiştirirseniz, aynı şey kaynakta da olur.

Kurşun Kalem Kodu aslında bu noktada daha iyi bir arayüzle aynı şeyi yapıyor . Kullandığı bloklar CoffeeScript AST'nin grafiksel bir görüntüsüdür. Öyleyse, bazıları blok yerleştirme özelliğini görsel sunumda açıkça netleştirmeseler de, çoğu çoğunun arkasında gerçek bir metin dili bulunmadığı halde, diğer blok veya fayans tabanlı sistemler de öyle mi? sözdizimi ağacı "biraz yanıltıcı olabilir, ancak prensibi orada.

Kaçırdığınız Öyleyse, bu sistemler gerçekten olmasıdır olan soyut sözdizimi ağacı doğrudan çalışma. Gördüğünüz ve manipüle ettiğiniz şey, bir ağacın alan açısından verimli bir görüntülenmesi, çoğu durumda kelimenin tam anlamıyla bir derleyici veya çözümleyici tarafından üretilen AST.

En az iki neden:

1. Çünkü kaynak kodu çok daha özlü bir sunumdur. Bir AST'yi grafik olarak yerleştirmek, çok daha fazla görsel gayrimenkul alacaktır.

   Programcılar mümkün olduğu kadar içeriğe sahip olduklarını - yani ekranda aynı anda birden fazla kod bulunduğunu gösterirler. Bağlam, karmaşıklığı daha iyi yönetmelerine yardımcı olur. (Bu, birçok programcının bu küçük yazı tiplerini ve 30 inçlik büyük ekranları kullanmasının bir nedenidir.)

   AST'yi bir grafik veya ağaç olarak göstermeye çalışırsak, o zaman tek bir ekrana sığabilecek kod miktarı kaynak kod olarak gösterilenden çok daha az olacaktır. Bu, geliştirici üretkenliği için çok büyük bir kayıp.

2. AST'ler, programlayıcılar tarafından kolay anlaşılması için değil, derleyici programlaması için tasarlanmıştır. Mevcut bir AST temsilini aldıysanız ve görsel olarak gösterdiyseniz, geliştiricilerin öğrenmesi kolay olacak şekilde tasarlanmadığı için geliştiricilerin anlaşması daha zor olacaktır.

   Buna karşılık, kaynak kodu genellikle edilir geliştiriciler tarafından anlaşılabilir / okunabilir olacak şekilde tasarlanmıştır; bu normalde kaynak kod için kritik bir tasarım kriteridir, ancak AST'ler için değildir. AST'lerin sadece derleyici yazarlar tarafından anlaşılması gerekir, günlük geliştiriciler tarafından değil.

   Ve, her durumda, AST dili, kaynak dilin yanı sıra geliştiricilerin öğrenmesi gereken ikinci bir dil olacaktır. Kazanmak değil.

Ayrıca bazı olası nedenler için /software//q/119463/34181 adresine bakın .

Derleyiciler tarafından tipik AST oldukça karmaşık ve ayrıntılı. Yönlendirilmiş grafik gösterimini takip etmek hızlı bir şekilde zorlaşacaktır. Ancak AST'lerin kullanıldığı iki büyük CS alanı vardır.

1. Lisp dilleri aslında AST olarak yazılmıştır. Program kaynak kodu listeler halinde yazılır ve derleyici ve / veya yorumlayıcı tarafından doğrudan kullanılır (hangi varyantın kullanıldığına bağlı olarak).
2. Dillerin modellenmesi, örneğin UML ve birçok görsel alana özgü dil, genel genel dil AST'den daha yüksek bir soyutlama düzeyinde soyut sözdizimi grafiklerini (ASG) etkileyen grafiksel gösterimleri kullanır.