Mengapa kita tidak menyimpan pohon sintaks alih-alih kode sumber?


111

Kami memiliki banyak bahasa pemrograman. Setiap bahasa diuraikan dan sintaks diperiksa sebelum diterjemahkan ke dalam kode sehingga pohon sintaksis abstrak (AST) dibangun.

Kami memiliki pohon sintaksis abstrak ini, mengapa kita tidak menyimpan struktur sintaksis ini alih-alih kode sumber (atau di sebelah kode sumber)?

Dengan menggunakan AST, bukannya kode sumber. Setiap programmer dalam sebuah tim dapat membuat serial pohon ini ke bahasa apa pun yang mereka inginkan (dengan tata bahasa bebas konteks yang sesuai) dan mengurai kembali ke AST ketika mereka selesai. Jadi ini akan menghilangkan perdebatan tentang pertanyaan gaya pengkodean (di mana menempatkan {dan}, di mana meletakkan spasi, lekukan, dll.)

Apa pro dan kontra dari pendekatan ini?


37
Lisp biasanya ditulis sebagai pohon sintaksis abstrak. Itu tidak menangkap sebanyak lebih banyak bahasa seperti Algol.
David Thornley

2
Saya tidak percaya bahwa David adalah satu-satunya yang menyebutkan bahwa program LISP adalah pohon sintaksis abstrak.
WuHoUnited

3
Selain poin lainnya: AST bahkan bukan hal terakhir. Tidak perlu waktu lama untuk membuat AST keluar dari kode. Ketika saya menjalankan StyleCop pada proyek VS2010 kecil-ish saya, ia menjalankan lusinan aturan berbasis AST yang berbeda pada ribuan baris kode dengan sangat cepat (kadang-kadang satu atau dua detik). Juga cukup mudah untuk memperluas StyleCop dan menulis aturan khusus. Saya menduga bahwa penguraian kode sumber menjadi AST adalah masalah yang dipahami dengan baik, dan relatif mudah. Ini datang dengan bahasa yang baik di tempat pertama, dan optimasi, dan semua perpustakaan yang sulit, tidak parsing.
Ayub

1
Setelah menguraikan kode, tidak mudah untuk menghasilkan kode untuk bahasa lain. (Bagaimana Anda menerjemahkan penyatuan implisit Prolog ke dalam C?). Sebagian besar yang Anda miliki adalah AST untuk program asli.
Ira Baxter

3
Masalah parsing dipahami dengan baik secara teknis, tetapi itu bukan tugas yang mudah untuk mem-parsing C atau C ++ karena mereka adalah bahasa kotor berantakan. Banyak kompiler parser C atau C ++ ke AST: Dentang, GCC, ... Mereka tidak dimaksudkan untuk penyimpanan program, dan GCC sangat ingin menjadi kompiler, bukan alat analisis program. Perangkat Rekayasa Ulang Perangkat Lunak DMS kami mem-parsing banyak dialek C dan C ++, menghasilkan AST, tabel simbol, dan berbagai jenis artefak analisis aliran. Pro besar dari pendekatan ini adalah kemampuan untuk membangun alat perubahan otomatis. semanticdesigns.com/Products/DMS/DMSToolkit.html
Ira Baxter

Jawaban:


72

Spasi dan Komentar

Umumnya AST tidak termasuk spasi, terminator garis, dan komentar.

Pemformatan Bermakna

Anda benar bahwa dalam kebanyakan kasus ini adalah positif (menghilangkan pemformatan perang suci), ada banyak kasus di mana pemformatan kode asli menyampaikan beberapa makna, seperti dalam string literal multi-line dan "kode paragraf" (memisahkan paragraf pernyataan dengan baris kosong).

Kode yang tidak bisa dikompilasi

Sementara banyak parser sangat tangguh terhadap sintaks yang hilang, kode dengan kesalahan sering menghasilkan pohon sintaks yang sangat aneh, yang bagus dan bagus sampai pada titik di mana pengguna memuat ulang file. Pernah membuat kesalahan dalam IDE Anda dan tiba-tiba seluruh file memiliki "squigglies"? Bayangkan bagaimana itu akan dimuat ulang dalam bahasa lain.

Mungkin pengguna tidak melakukan kode yang tidak dapat dipecahkan, tetapi mereka tentu saja perlu menyimpan secara lokal.

Tidak ada dua bahasa yang cocok dengan sempurna

Seperti yang telah ditunjukkan orang lain, hampir tidak ada dua bahasa yang memiliki paritas fitur yang sempurna. Yang paling dekat yang dapat saya pikirkan adalah VB dan C #, atau JavaScript dan CoffeeScript, tetapi meskipun demikian VB memiliki fitur seperti XML Literals yang tidak memiliki padanan yang setara dalam C #, dan konversi JavaScript ke CoffeeScript dapat menghasilkan banyak literal JavaScript.

Pengalaman pribadi:

Dalam aplikasi perangkat lunak yang saya tulis, kita sebenarnya perlu melakukan ini, karena pengguna diharapkan untuk memasukkan ekspresi "bahasa Inggris biasa" yang dikonversi ke JS di latar belakang. Kami dianggap hanya menyimpan versi JS, tetapi tidak menemukan cara yang dapat diterima untuk melakukan hal itu sehingga dapat dimuat dan dibongkar dengan benar, sehingga kami akhirnya selalu menyimpan teks pengguna dan versi JS, serta bendera yang menunjukkan jika "plain english "Versi terurai sempurna atau tidak.


9
Ada parser yang menangkap komentar dan tata letak di AST. Perangkat Rengineering Perangkat Lunak DMS kami melakukan ini dengan baik. Itu memang mengalami kesulitan dengan kode ilegal; ini memiliki pengurai bahasa yang tepat.
Ira Baxter

2
Sebenarnya ada alat yang mengubah Javascript ke CoffeeScript , jadi saya pikir JavaScript dan CoffeScript saling diterjemahkan tanpa literal Javascript.
Peter Olson

Alat yang menarik, Peter, saya tidak menyadarinya.
Kevin McCormick

+1 untuk pemformatan yang berarti dan pengalaman pribadi yang menarik. - Ruang putih tidak penting untuk pertanyaan dan komentar dapat disimpan. Kode dengan kesalahan akan tetap lebih mudah untuk diperbaiki dan tentu saja bagian "satu bahasa untuk mengatur semuanya" tidak dapat dijangkau.
cregox

43

Mengapa kita tidak menyimpan pohon sintaks ini alih-alih kode sumber? Setiap programmer dalam tim dapat membuat serial pohon ini ke bahasa apa pun, yang mereka inginkan dan menguraikan kembali ke AST ketika mereka selesai.

Memang, itu ide yang masuk akal. Microsoft memiliki proyek penelitian pada 1990-an untuk melakukan hal itu .

Beberapa skenario muncul dalam pikiran.

Yang pertama agak sepele; seperti yang Anda katakan, Anda bisa membuat AST dirender ke dalam tampilan yang berbeda tergantung pada preferensi programmer yang berbeda untuk hal-hal seperti spasi dan sebagainya. Tetapi menyimpan AST terlalu banyak untuk skenario itu; cukup tulis sendiri printer cantik. Ketika Anda memuat file ke editor Anda, jalankan printer cantik untuk memasukkannya ke dalam format yang Anda sukai, dan kembali ke format asli ketika Anda menyimpannya.

Yang kedua lebih menarik. Jika Anda dapat menyimpan pohon sintaksis abstrak maka perubahan kode menjadi tidak tekstual melainkan sintaksis. Refactor di mana kode dipindahkan menjadi lebih mudah dimengerti. Sisi buruknya tentu saja bahwa menulis algoritma pohon-diff tidak sepele dan sering harus dilakukan berdasarkan per-bahasa. Teks diff berfungsi untuk hampir semua bahasa.

Yang ketiga lebih seperti apa yang Simonyi bayangkan untuk Intentional Programming: bahwa konsep dasar yang umum untuk bahasa pemrograman adalah apa yang diserialisasi, dan kemudian Anda memiliki pandangan berbeda tentang konsep-konsep yang diberikan dalam bahasa yang berbeda. Meskipun ide yang indah, fakta jeleknya adalah bahwa bahasa cukup berbeda dalam perinciannya sehingga pendekatan penyebut-umum-rendah tidak benar-benar berfungsi.

Jadi, singkatnya, ini adalah ide yang bagus tetapi ini merupakan pekerjaan ekstra yang sangat besar untuk manfaat yang relatif kecil. Itu sebabnya hampir tidak ada yang melakukannya.


3
Sebenarnya, Anda dapat melakukan diff pohon dalam cara yang independen bahasa. Anda memang membutuhkan parser khusus bahasa untuk membangun pohon. Lihat jajaran alat Smart Difencer kami, yang membandingkan AST untuk banyak bahasa. Mereka semua menggunakan mesin diff yang sama. semanticdesigns.com/Products/SmartDifferencer
Ira Baxter

1
Saya berharap untuk melihat gaya tim saya cantik-cetak-on-load-gaya-cantik-cetak-di-simpan di Visual Studio suatu hari ... berharap selama bertahun-tahun ... belum beruntung ...
Roman Starkov

19

Anda bisa berpendapat bahwa ini adalah kode byte apa yang ada di .NET. Program reflektor Infact redgate menerjemahkan kode byte kembali ke berbagai bahasa pemrograman .NET.

Namun, ada masalah. Sintaks adalah spesifik bahasa sebanyak ada hal-hal yang dapat Anda wakili pada satu bahasa yang tidak memiliki representasi dalam bahasa lain. Ini terjadi di .NET dengan C ++ menjadi satu-satunya bahasa .NET yang memiliki akses ke semua 7 tingkat akses.

Di luar lingkungan .NET itu menjadi jauh lebih rumit. Setiap bahasa kemudian mulai memiliki set sendiri perpustakaan terkait. Tidak mungkin untuk mencerminkan sintaksis generik dalam C dan Java yang mencerminkan eksekusi instruksi yang sama ketika mereka memecahkan masalah simular dengan cara yang sangat berbeda.


5
Pernah mencoba mendekompilasi MSIL yang diproduksi oleh F #?
SK-logic

12

Saya agak menyukai beberapa ide Anda, tetapi Anda terlalu banyak memperkirakan betapa mudahnya menerjemahkan bahasa ke bahasa. Jika semudah itu, Anda bahkan tidak perlu menyimpan AST, karena Anda selalu dapat menguraikan bahasa X ke dalam AST kemudian beralih dari AST ke bahasa Y.

Namun, saya berharap spesifikasi kompiler berpikir lebih banyak tentang mengekspos beberapa AST melalui beberapa jenis API. Hal-hal seperti pemrograman berorientasi aspek, refactoring, dan analisis program statis dapat diimplementasikan melalui API seperti itu, tanpa pelaksana kemampuan tersebut harus mengulang begitu banyak pekerjaan yang sudah dilaksanakan oleh penulis kompiler.

Sungguh aneh seberapa sering struktur data programmer untuk mewakili suatu program adalah sebagai kumpulan file yang berisi string.


5
Sudahkah Anda mengikuti pengembangan proyek Microsoft " Roslyn " untuk membuka kompiler VBc dan C # sebagai API? Tersedia rilis pratinjau.
Carson63000

11

Saya pikir poin yang paling menonjol adalah:

  • Tidak ada manfaatnya. Anda mengatakan bahwa itu berarti semua orang bisa menggunakan bahasa hewan peliharaan mereka. Tapi itu tidak benar - menggunakan representasi sintaksis pohon akan menghilangkan perbedaan sintaksis saja, tetapi bukan yang semantik. Ia bekerja sampai batas tertentu untuk bahasa yang sangat mirip - seperti VB dan C #, atau Java dan Scala. Tetapi bahkan tidak ada di sana sepenuhnya.

  • Itu bermasalah. Anda telah memperoleh kebebasan bahasa, tetapi Anda kehilangan kebebasan alat. Anda tidak lagi dapat membaca dan mengedit kode dalam editor teks, atau bahkan IDE apa pun - Anda bergantung pada alat khusus yang berbicara dengan perwakilan AST Anda untuk membaca dan mengedit kode. Tidak ada yang didapat di sini.

    Untuk mengilustrasikan poin terakhir ini, lihat RealBasic, yang merupakan implementasi eksklusif dari dialek BASIC yang kuat. Untuk sementara waktu, sepertinya bahasa itu bisa lepas landas, tapi itu sepenuhnya tergantung pada vendor, sampai-sampai Anda hanya bisa melihat kode dalam IDE mereka karena disimpan dalam format non-teks eksklusif. Kesalahan besar .


4
Manfaat potensial adalah bahwa hal itu dapat mengakhiri perdebatan tanpa akhir seperti "tabs vs space", "unix vs windows bracing / indentation", "awalan m_ di depan anggota atau tidak", karena mereka dapat diubah menjadi opsi IDE sederhana.
nikie

1
@nikie Benar tetapi Anda sudah bisa melakukan ini menggunakan alat pemformatan ulang - seperti astyleatau UnniversalIndent. Tidak perlu untuk format biner misterius.
Konrad Rudolph

2
Manfaat sebenarnya adalah potensi untuk memiliki alat diff / patch yang memberi Anda pemahaman yang lebih baik tentang apa yang benar-benar berubah. Tapi itu sepertinya menyiratkan membutuhkan seluruh toolchain baru untuk kontrol versi, yang merupakan batasan serius.
Peter Taylor

1
Jika Anda berpikir "Tidak ada manfaatnya," maka Anda belum melihat Domain Workbench Perangkat Lunak yang Disengaja.
Craig Stuntz

1
Singkatnya, logika yang sama dapat diproyeksikan ke representasi yang berbeda, tidak semua berbasis teks, membuat aturan dapat diakses oleh non-programmer. Misalnya, pakar domain seperti aktuaris dapat menulis bagian aktuaria dari aplikasi asuransi. Seperti DSL kecuali tidak terbatas pada representasi itu. Ini sangat terkait dengan pertanyaan itu. Ada demo yang bagus .
Craig Stuntz

6

Saya pikir, jika Anda menyimpan teks dan AST, maka Anda belum benar-benar menambahkan sesuatu yang bermanfaat, karena teks sudah ada dalam satu bahasa, dan AST dapat dengan cepat direkonstruksi dari teks.

Di sisi lain, jika Anda hanya menyimpan AST, Anda kehilangan hal-hal seperti komentar yang tidak dapat dipulihkan.


6
dan jika Anda membuat bagian komentar dari pohon sintaks (dengan node komentar yang bisa menjadi anak dari apa pun)?
ratchet freak

Alat kami melakukan hal itu. Lihat komentar saya yang lain di utas ini.
Ira Baxter

4

Saya percaya idenya menarik dalam teori tetapi tidak terlalu praktis karena bahasa pemrograman yang berbeda mendukung konstruksi yang berbeda yang tidak memiliki padanan dalam bahasa lain.

Misalnya, X ++ memiliki pernyataan 'saat pilih' yang tidak dapat ditulis dalam C # tanpa banyak kode tambahan (kelas tambahan, logika tambahan, dll). http://msdn.microsoft.com/en-us/library/aa558063.aspx

Apa yang saya katakan di sini adalah bahwa banyak bahasa memiliki gula sintaksis yang diterjemahkan dalam blok besar kode bahasa yang sama atau bahkan elemen yang tidak ada sama sekali dalam bahasa lain. Berikut adalah contoh mengapa pendekatan AST tidak akan berfungsi:

Bahasa X memiliki kata kunci K yang diterjemahkan, dalam AST dalam 4 pernyataan: S1, S2, S3 dan S4. AST sekarang diterjemahkan dalam bahasa Y dan seorang programmer mengubah S2. Sekarang apa yang terjadi dengan terjemahan kembali ke X? Kode ini diterjemahkan sebagai 4 pernyataan, bukan satu kata kunci ...

Argumen terakhir yang menentang pendekatan AST adalah fungsi platform: apa yang terjadi ketika suatu fungsi tertanam dalam platform? Seperti .NET's Environment.GetEnvironmentVariable. Bagaimana Anda menerjemahkannya?


4

Ada sistem yang dibangun di sekitar gagasan ini: JetBrains MPS . Editor sedikit aneh, atau hanya berbeda, tetapi secara umum itu bukan masalah besar. Masalah terbesar adalah, baik, bahwa tidak teks lagi, sehingga Anda tidak dapat menggunakan salah satu alat berbasis teks normal - editor lain, grep, sed, menggabungkan dan diff alat, dll


2
... tetapi Anda mendapatkan banyak fitur editor di luar kotak. Pertimbangkan untuk sedikit memperluas jawaban ini, ini adalah teknologi yang sangat menarik yang pantas membahas lebih dalam tentang keuntungan tidak menyimpan kode sumber sebagai teks. Misalnya ketika saya menjawab pertanyaan ini pada tab vs spasi .
Steven Jeuris 11/11/11

AST dapat disimpan dalam format yang dapat dibaca manusia dan bukan dalam biner. dapatkah Anda sekarang dengan alat-alat linux misalnya mengganti setiap metode dalam kode yang mengambil sebagai parameter objek serializable? akan sangat sulit untuk menulis, tetapi AST membuatnya sangat mudah.
IAdapter

1
Orang-orang terus menerus melakukan kesalahan ini. AST membuatnya lebih mudah daripada jika Anda hanya memiliki teks mentah. Tetapi untuk sesuatu yang menarik, Anda memerlukan banyak informasi tambahan: kontrol dan aliran data, tabel simbol, analisis rentang, ... AST membantu tetapi hanya sebagian kecil dari apa yang benar-benar dibutuhkan.
Ira Baxter

@Ira Baxter, tentu saja lebih mudah dengan AST. Tetapi jauh lebih sulit untuk diintegrasikan ke dalam infrastruktur yang ada .
SK-logic

4

Sebenarnya ada beberapa produk, umumnya dikenal sebagai "meja kerja bahasa" yang menyimpan AST dan menyajikan, dalam editor mereka, "proyeksi" AST kembali ke bahasa tertentu. Seperti yang dikatakan @ sk-logic, MPS JetBrains adalah salah satu sistem tersebut. Yang lainnya adalah Intentional Workbench Software Intentional.

Potensi meja kerja bahasa tampaknya sangat tinggi, terutama di bidang bahasa khusus domain, karena Anda dapat membuat proyeksi khusus domain. Sebagai contoh, demo sengaja DSL yang berkaitan dengan listrik yang diproyeksikan sebagai diagram sirkuit - jauh lebih mudah dan lebih akurat bagi pakar domain untuk berdiskusi dan mengkritik daripada sirkuit yang dijelaskan dalam bahasa pemrograman berbasis teks.

Dalam praktiknya, meja kerja bahasa lambat untuk dipahami karena, selain dari pekerjaan DSL, pengembang mungkin lebih suka bekerja dalam bahasa pemrograman yang umum dan umum. Jika dibandingkan head-to-head dengan editor teks atau IDE pemrograman, meja kerja bahasa memiliki banyak overhead dan keuntungan mereka hampir tidak jelas. Tak satu pun dari meja kerja bahasa yang saya lihat memiliki boot yang terikat pada titik di mana mereka dapat dengan mudah memperluas IDE mereka sendiri - yaitu, jika meja kerja bahasa bagus untuk produktivitas, mengapa alat workbench bahasa tidak menjadi lebih baik -dan-lebih baik dengan laju lebih cepat dan lebih cepat?


"meja kerja bahasa" tidak harus didasarkan pada penyimpanan AST mentah. Mereka juga bisa berorientasi pada sintaks teks biasa, lihat misalnya meta-alternative.net/pfront.pdf (dan ini sebenarnya memperluas editor Visual Studio dan Emacs dengan eDSL yang diterapkan di atasnya).
SK-logic

Itu makalah yang menarik; itu mengingatkan saya (dalam ambisi, sama sekali tidak dalam implementasi) alat bernama SugarJ yang dipresentasikan di SPLASH / OOPSLA beberapa minggu lalu: uni-marburg.de/fb12/ps/research/sugarj
Larry OBrien

menarik, saya akan coba yang itu juga.
SK-logic

3

Anda telah membaca pikiran saya.

Ketika saya mengambil kursus kompiler, beberapa tahun yang lalu, saya menemukan bahwa jika Anda mengambil AST dan membuat serial, dengan notasi awalan alih-alih notasi infiks biasa, dan menggunakan tanda kurung untuk membatasi seluruh pernyataan, Anda mendapatkan Lisp. Sementara saya belajar tentang Skema (dialek Lisp) dalam studi sarjana saya, saya tidak pernah benar-benar mendapatkan penghargaan untuk itu. Saya benar-benar mendapatkan apresiasi untuk Lisp dan dialeknya, sebagai hasil dari kursus itu.

Masalah dengan apa yang Anda usulkan:

  1. sulit / lambat untuk menyusun AST dalam lingkungan grafis. Lagipula, kebanyakan dari kita bisa mengetik lebih cepat daripada menggerakkan mouse. Namun, pertanyaan yang muncul adalah "bagaimana Anda menulis kode program dengan tablet?" Mengetik pada tablet lambat / rumit, dibandingkan dengan keyboard / laptop dengan keyboard perangkat keras. Jika Anda dapat membuat AST dengan menyeret dan menjatuhkan komponen dari palet ke atas kanvas pada layar yang besar, pemrograman perangkat layar sentuh pada tablet dapat menjadi hal yang nyata.

  2. sedikit / tidak ada alat kami yang ada mendukung ini. Kami memiliki puluhan tahun pengembangan untuk menciptakan IDE yang semakin kompleks dan editor yang semakin cerdas. Kami memiliki semua alat ini untuk memformat ulang teks, membandingkan teks, mencari teks. Di mana alat yang dapat melakukan hal yang setara dengan pencarian ekspresi reguler di pohon? Atau beda dua pohon? Semua hal ini mudah dilakukan dengan teks. Tapi mereka hanya bisa membandingkan kata-katanya. Ubah nama variabel, sehingga kata-katanya berbeda tetapi makna semantiknya sama, dan alat-alat yang berbeda itu mengalami masalah. Alat-alat seperti itu, dikembangkan untuk beroperasi pada AST dan bukan teks, akan memungkinkan Anda untuk lebih dekat dengan membandingkan makna semantik. Itu akan menjadi Hal yang Baik.

  3. sementara mengubah kode sumber program menjadi AST relatif dipahami dengan baik (kami memiliki kompiler dan penerjemah, bukan?), mengubah AST menjadi kode program tidak begitu dipahami dengan baik. Mengalikan dua bilangan prima untuk mendapatkan bilangan komposit yang besar relatif mudah tetapi memfaktorkan bilangan komposit yang besar kembali ke bilangan prima jauh lebih sulit; di situlah kita dengan parsing vs AST dekompilasi. Di situlah perbedaan antar bahasa menjadi masalah. Bahkan dalam bahasa tertentu, ada beberapa cara untuk mendekompilasi AST. Iterasi melalui kumpulan objek dan mendapatkan semacam hasil, misalnya. Gunakan for for, iterasi melalui array? Itu akan kompak dan cepat, tetapi ada batasan. Gunakan semacam Iterator, beroperasi pada Koleksi? Koleksi itu bisa berukuran variabel, yang menambah fleksibilitas dengan mengorbankan kecepatan (mungkin). Peta / Kurangi? Lebih kompleks, tetapi secara implisit diparalelkan. Dan itu hanya untuk Java, tergantung pada preferensi Anda.

Pada waktunya, upaya pengembangan akan dikeluarkan dan kami akan mengembangkan menggunakan layar sentuh dan AST. Mengetik akan menjadi kurang dari keharusan. Saya melihat itu sebagai perkembangan logis dari tempat kita berada, melihat bagaimana kita menggunakan komputer, hari ini, itu akan menyelesaikan # 1.

Kami sudah bekerja dengan pohon. Lisp hanyalah AST serial. XML (dan HTML, dengan ekstensi) hanyalah pohon serial. Untuk melakukan pencarian, kami sudah memiliki beberapa prototipe: XPath dan CSS (masing-masing untuk XML dan HTML). Ketika alat grafis dibuat yang memungkinkan kami membuat pemilih dan pengubah gaya CSS, kami akan menyelesaikan bagian # 2. Ketika penyeleksi tersebut dapat diperluas untuk mendukung regex, kami akan lebih dekat. Masih mencari alat diff grafis yang bagus untuk membandingkan dua dokumen XML atau HTML. Ketika orang mengembangkan alat-alat itu, # 2 akan dapat dipecahkan. Orang-orang sudah mengerjakan hal-hal seperti itu; mereka belum ada di sana.

Satu-satunya cara saya dapat melihat untuk mendekompilasi ASTs ke bahasa pemrograman teks akan menjadi sesuatu yang mencari tujuan. Jika saya memodifikasi kode yang ada, tujuannya mungkin dapat dicapai dengan suatu algoritma yang membuat kode saya yang dimodifikasi sedekat mungkin dengan kode awal (minimal textual diff). Jika saya menulis kode dari awal, tujuannya mungkin kode terkecil, paling ketat (kemungkinan untuk perulangan). Atau mungkin kode yang diparalelkan seefisien mungkin (kemungkinan peta / pengurangan atau sesuatu yang melibatkan CSP). Jadi, AST yang sama dapat menghasilkan kode yang sangat berbeda, bahkan dalam bahasa yang sama, berdasarkan pada bagaimana tujuan ditetapkan. Mengembangkan sistem seperti itu akan menyelesaikan # 3. Ini akan menjadi kompleks secara komputasional, artinya kita mungkin perlu semacam pengaturan client-server,


1

Jika maksud Anda adalah untuk menghilangkan perdebatan tentang memformat gaya, maka mungkin yang Anda inginkan adalah editor yang membaca dalam file sumber, memformatnya ke preferensi pribadi Anda untuk tampilan dan pengeditan, tetapi ketika menyimpannya, memformat ulang ke gaya yang dipilih tim menggunakan.

Sangat mudah jika Anda menggunakan editor seperti Emacs . Mengubah gaya pemformatan seluruh file adalah pekerjaan perintah tiga.

Anda juga harus dapat membuat kait untuk secara otomatis mengubah file ke gaya Anda saat memuat, dan mengubahnya menjadi gaya tim saat menyimpan.


1
Maka Anda masih perlu diff semantik dan gabungkan (yaitu, sekali lagi, AST-level).
SK-logic

Tidak, editor memformat kembali ke gaya tim untuk menyimpan sumber - jadi Anda akan membandingkan satu jenis sumber dengan jenis yang sama.
Gustav Bertram

titik yang baik, satu representasi yang dinormalisasi memecahkan semua masalah
SK-logic

1
Tidak, itu hanya memecahkan masalah masalah komparting dua file untuk identitas. Jika Anda ingin melihat perbedaan antara file, Anda idealnya membutuhkan sesuatu yang mengerti struktur. Saya suka emacs saya, tetapi tidak mengerti struktur.
Ira Baxter

Emacs hebat, tapi saya tidak pernah menggunakannya untuk diff. Untuk membedakan hierarki sumber saya sebelum check-in, saya selalu menggunakan berbaur . Ini benar-benar mengerti SVN dan git. Di Windows, saya akan menggunakan WinMerge mungkin dalam kombinasi dengan kura-kura.
Gustav Bertram

1

Sulit untuk membaca dan memodifikasi AST, alih-alih kode sumber.

Namun, beberapa alat terkait kompiler memungkinkan untuk menggunakan AST. Java bytecode dan .NET Intermediate code berfungsi mirip dengan AST.


1
Lebih mudah untuk memodifikasi AST dengan alat mekanik secara andal, daripada melakukannya dengan teks. Anda dapat melakukan ini dengan perubahan yang diarahkan pada pola. Lihat semanticdesigns.com/Products/DMS/ProgramTransformation.html
Ira Baxter

2
Ceritakan ini kepada LISPers sekarang ...
hugomg

@Ira Baxter. Saya tahu, saya benar-benar bekerja pada alat visual kustom yang bekerja langsung dengan AST, namun, kadang-kadang, pengembang harus bekerja dengan teks, bukan visual. Beberapa AST juga direpresentasikan sebagai bahasa pemrograman yang lebih pendek dalam teks.
umlcat

@umlcat, bisakah Anda ceritakan lebih banyak tentang pekerjaan Anda pada alat visual untuk AST?
Daniel Albuschat

@Daniel Albuschat Saya mengerjakan proyek bahasa pemrograman hewan peliharaan. Pengurai ini sulit diimplementasikan, jadi saya melewatkannya, untuk saat ini, dan membuat alat di mana saya menunjukkan AST (form dengan treeview control), & menambahkan ekspresi secara langsung. Dan dapat melakukan yang sebaliknya, menghasilkan kode dari AST.
umlcat

0

itu ide yang bagus; tetapi AST masing-masing bahasa berbeda dari yang lain.

satu-satunya pengecualian yang saya tahu adalah untuk VB.NET dan C #, di mana microsoft berpendapat bahwa mereka "bahasa yang sama persis dengan sintaks yang berbeda". Bahkan bahasa .NET lainnya (IronPython, F #, apa pun) berbeda pada tingkat AST.

Hal yang sama dengan bahasa JVM, mereka semua menargetkan bytecode yang sama, tetapi konstruk bahasanya berbeda, menjadikannya bahasa yang berbeda dan AST yang berbeda.

Bahkan bahasa 'lapisan tipis', seperti CoffeScript dan Xtend berbagi banyak teori tentang bahasa yang mendasari (JavaScript dan Java, masing-masing); tetapi memperkenalkan konsep tingkat tinggi yang (atau harus) dipertahankan di tingkat AST.

jika Xtend dapat direkonstruksi dari Java AST, saya pikir itu akan didefinisikan sebagai 'uncompiler' Java-to-Xtend yang secara ajaib membuat abstraksi level yang lebih tinggi dari kode Java yang ada, bukan begitu?


1
Sebagai seseorang yang akrab dengan kompiler C # dan VB saya dapat memberitahu Anda bahwa mereka pasti serupa tetapi ada cukup detail penting yang cukup berbeda sehingga tidak praktis untuk memperlakukan mereka sebagai "bahasa yang sama dengan sintaks yang berbeda". Kami mempertimbangkan melakukan itu untuk proyek Roslyn; membangun satu kompiler yang dapat mengkompilasi kedua bahasa dengan fasilitas yang sama - dan setelah banyak perdebatan memutuskan untuk menggunakan dua kompiler untuk dua bahasa.
Eric Lippert 11/11

@EricLippert: itu memalukan. Bukan berarti saya pernah berencana belajar bahasa apa pun, tapi itu terdengar seperti pengecualian yang bagus. Saya pikir htat membiarkan lisp-like-Dylan dan algol-like-Dylan sebagai satu-satunya 'bahasa yang sama dengan contoh sintaks yang berbeda'.
Javier
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.