8 poin oleh dalinaum 2021-04-02 | 3 komentar | Bagikan ke WhatsApp

Terjemahan dari tulisan yang diunggah oleh pengembang bahasa Go, Russ Cox, pada tahun 2010.

  • Ada mitos yang menyebar bahwa generator parser seperti yacc tidak dapat menghasilkan error sintaks dengan baik.

  • Namun masalah ini sudah dipecahkan oleh Clinton Jeffery pada tahun 2003, dan bukan masalah yang harus diselesaikan dengan menulis parser secara manual.

  • Jika mencari kecocokan untuk state dan token input di tabel (bison), kita bisa menggunakan error yang lebih baik daripada sekadar error sintaks sederhana.

3 komentar

 
lifthrasiir 2021-04-02

(Berikut ini adalah ringkasan dari tulisan yang saya posting di server Discord Rust Korea.)

Masalah terbesar tulisan ini adalah: jadi, apakah Go sekarang memakai parser generator? Tidak. Parser utama Go masih ditulis dengan tangan. Alasannya saya juga tidak begitu tahu, tetapi kemungkinan besar meskipun rsc menganggapnya oke, pengembang Go lainnya tidak lantas berpikir demikian.

Jika dianalogikan ke compiler, ide Jeffrey bisa dibandingkan dengan peephole optimizer. Sebelum mengeluarkan kode mesin, ia menyimpan sejumlah tetap instruksi kode mesin yang baru saja dihasilkan—karena itulah disebut peephole, "lubang intip" ke dalam window tersebut—lalu jika melihat pola tertentu, ia langsung mengganti instruksi itu dengan instruksi yang lebih cepat. Peephole optimizer adalah alat yang praktis karena bisa dipakai berdampingan dengan pass optimisasi umum lainnya, tetapi hanya dengan peephole optimizer saja, Anda tidak bisa melakukan semua jenis optimisasi yang dibutuhkan compiler. Demikian juga, pendekatan yang menghasilkan error dari token-token terbaru tidak bisa mencakup semua error parsing. Lagi pula, ini adalah pendekatan yang berdiri sendiri dan bisa diterapkan bahkan tanpa parser generator, jadi tidak tepat untuk mengklaim bahwa keberadaan pendekatan ini menghilangkan masalah parser generator.

Secara pribadi, menurut saya yang buruk bukanlah konsep parser generator itu sendiri, melainkan cara berpikir yang "dipaksakan" oleh parser generator. Saat menulis parser, entah itu dihasilkan otomatis atau ditulis dengan tangan, Anda tetap harus mempertimbangkan left recursion dan right recursion, dan tidak bisa begitu saja menuangkan tata bahasa yang "alami" langsung menjadi kode. Kalau ditulis dengan tangan, ya itu memang konsekuensi yang diterima. Namun jika setelah memakai parser generator pun tetap harus menulis sesuai subset dari "grammar" yang terikat pada algoritma parsing tertentu seperti LL/LR, maka kelebihan generator itu pun berkurang setengahnya. (Algoritma seperti GLR memang memberi ruang gerak yang lebih besar, tetapi tetap ada batasnya.) Ada alasan mengapa saat ini sebagian besar implementasi bahasa tingkat production tidak memakai parser generator, atau kalaupun memakai, kadang memilih pendekatan seperti PEG yang memang parser generator tetapi sama sekali tidak mengambil kelebihan parser generator yang umum.

 
dynalloc 2021-04-02

Saya paham kalau orang enggan memakai parser generator karena tidak mau terikat pada tata bahasa yang dibatasinya, tetapi tetap aneh kalau sampai mengklaim bahwa parser generator memaksakan tata bahasa tertentu kepada pengguna.

Parser generator muncul untuk membantu karena pembuatan tabel parsing untuk tata bahasa LR, yang punya keunggulan parsing waktu linear, terlalu sulit. Menghasilkan tata bahasa context-sensitive yang non-deterministik saat parsing, atau parser rekursif yang bahkan tidak jelas kapan parsingnya akan berakhir, mungkin bukanlah hal yang menjadi perhatian para peneliti/pengembang parser generator.

Karena itu, saya rasa parser generator bukanlah program yang membabi buta memuja dan memaksakan tata bahasa LR/LALR yang tidak intuitif, melainkan alat yang menjalankan perannya dengan baik untuk memecahkan masalah yang sangat sulit, yaitu parsing waktu linear dan pembuatan tabel parsing untuk itu.

 
lifthrasiir 2021-04-05

Hampir semua bahasa yang dapat dijumpai di dunia nyata memiliki tata bahasa LL(1), sehingga parsing waktu linear dimungkinkan tanpa harus menggunakan parser LR. (Ini bukan berarti tata bahasa yang dipilih untuk bahasa tersebut adalah LL(1).) Karena itu, pernyataan bahwa untuk parsing waktu linear harus menggunakan parser LR, dan karena sulit membuat tabel parsing maka diperlukan generator, membalik hubungan sebab-akibat. Selain itu, proses pembuatan tabel parsing itu sendiri pada dasarnya tidak rumit (yang sulit adalah pembuktian algoritmanya).