lexers vs parser

Apakah lexers dan parser benar-benar berbeda dalam teori?

Tampaknya modis untuk membenci ekspresi reguler: pengkodean horor , posting blog lain .

Namun, alat berbasis lexing yang populer: pygments , geshi , atau prettify , semuanya menggunakan ekspresi reguler. Mereka tampaknya lex apa pun ...

Kapan cukup lexing, kapan Anda membutuhkan EBNF?

Adakah yang menggunakan token yang diproduksi oleh para lexer ini dengan generator parser bison atau antlr?

Apa kesamaan parser dan lexer:

1. Mereka membaca simbol beberapa alfabet dari masukan mereka.

   • Petunjuk: Alfabet tidak harus berupa huruf. Tetapi harus simbol yang atom untuk bahasa dipahami oleh parser / lexer.
   • Simbol untuk lexer: karakter ASCII.
   • Simbol untuk parser: token tertentu, yang merupakan simbol terminal dari tata bahasa mereka.

2. Mereka menganalisis simbol - simbol ini dan mencoba mencocokkannya dengan tata bahasa yang mereka pahami.
   

   • Di sinilah letak perbedaan sebenarnya. Lihat di bawah untuk lebih lanjut.
   • Tata bahasa dipahami oleh lexers: tata bahasa biasa (level 3 Chomsky).
   • Tata bahasa dipahami oleh parser: tata bahasa bebas konteks (level 2 Chomsky).

3. Mereka melampirkan semantik (makna) ke potongan bahasa yang mereka temukan.

   • Lexers melampirkan makna dengan mengklasifikasikan leksem (string simbol dari input) sebagai token tertentu . Misalnya Semua leksem ini: *, ==, <=, ^akan diklasifikasikan sebagai "operator" token dengan C / C ++ lexer.
   • Parser melampirkan makna dengan mengklasifikasikan string token dari input (kalimat) sebagai nonterminals tertentu dan membangun pohon parse . Misalnya semua ini string tanda: [number][operator][number], [id][operator][id], [id][operator][number][operator][number]akan diklasifikasikan sebagai "ekspresi" nonterminal oleh C / C ++ parser.

4. Mereka dapat melampirkan beberapa makna tambahan (data) ke elemen yang dikenali.

   • Ketika lexer mengenali urutan karakter yang merupakan angka yang tepat, ia dapat mengubahnya menjadi nilai binernya dan menyimpannya dengan token "angka".
   • Demikian pula, ketika parser mengenali suatu ekspresi, ia dapat menghitung nilainya dan menyimpannya dengan simpul "ekspresi" dari pohon sintaksis.

5. Mereka semua menghasilkan kalimat yang tepat dari bahasa yang mereka kenali.

   • Lexers menghasilkan token , yang merupakan kalimat dari bahasa reguler yang mereka kenali. Setiap token dapat memiliki sintaksis dalam (meskipun level 3, bukan level 2), tetapi itu tidak masalah untuk data output dan untuk yang membacanya.
   • Parser menghasilkan pohon sintaks , yang merupakan representasi kalimat dari bahasa bebas konteks yang mereka kenali. Biasanya hanya satu pohon besar untuk seluruh dokumen / file sumber, karena seluruh dokumen / file sumber adalah kalimat yang tepat untuk mereka. Tetapi tidak ada alasan mengapa parser tidak dapat menghasilkan serangkaian pohon sintaks pada hasilnya. Misalnya itu bisa menjadi pengurai yang mengenali tag SGML yang ditempel ke teks biasa. Sehingga akan tokenize dokumen SGML menjadi serangkaian token: [TXT][TAG][TAG][TXT][TAG][TXT]....

Seperti yang Anda lihat, parser dan tokenizer memiliki banyak kesamaan. Satu parser bisa menjadi tokenizer untuk parser lain, yang membaca token inputnya sebagai simbol dari alfabetnya sendiri (token hanyalah simbol dari beberapa alfabet) dengan cara yang sama seperti kalimat dari satu bahasa dapat menjadi simbol alfabet dari yang lain, level yang lebih tinggi bahasa. Misalnya, jika *dan -merupakan simbol alfabet M(sebagai "simbol kode Morse"), maka Anda dapat membuat parser yang mengenali string dari titik-titik dan garis-garis ini sebagai huruf yang disandikan dalam kode Morse. Kalimat dalam bahasa "Morse Code" bisa menjadi token untuk parser lain, yang token iniadalah simbol atom dari bahasanya (mis. Bahasa "Kata-kata Bahasa Inggris"). Dan "Kata Bahasa Inggris" ini bisa menjadi token (simbol alfabet) untuk beberapa parser tingkat tinggi yang mengerti bahasa "Kalimat Bahasa Inggris". Dan semua bahasa ini hanya berbeda dalam kompleksitas tata bahasa . Tidak ada lagi.

Jadi ada apa dengan "level tata bahasa Chomsky" ini? Nah, Noam Chomsky mengklasifikasikan tata bahasa menjadi empat tingkat tergantung pada kompleksitasnya:

• Level 3: Tata bahasa reguler

  Mereka menggunakan ekspresi reguler, yaitu, mereka dapat hanya terdiri dari simbol-simbol alfabet ( a, b), concatenations mereka ( ab, aba, bbbETD.), Atau alternatif (misalnya a|b).
  Mereka dapat diimplementasikan sebagai finite state automata (FSA), seperti NFA (Nondeterministic Finite Automaton) atau DFA yang lebih baik (Deterministic Finite Automaton).
  Tata bahasa reguler tidak dapat menangani sintaks bertingkat , mis. Tanda kurung bersarang / cocok dengan benar (()()(()())), tag HTML / BB bersarang, blok bersarang dll. Karena state automata untuk menanganinya harus memiliki banyak negara bagian yang tak terhingga untuk menangani level bersarang yang tak terhingga banyaknya.

• Level 2: Tata bahasa bebas konteks

  Mereka dapat memiliki cabang bersarang, rekursif, mirip dengan diri sendiri di pohon sintaksis mereka, sehingga mereka dapat menangani dengan baik struktur bersarang.
  Mereka dapat diimplementasikan sebagai otomat negara dengan stack. Tumpukan ini digunakan untuk mewakili level sintaks yang bersarang. Dalam praktiknya, mereka biasanya diimplementasikan sebagai parser top-down, recursive-descent yang menggunakan stack panggilan prosedur mesin untuk melacak tingkat bersarang, dan menggunakan prosedur / fungsi yang disebut secara rekursif untuk setiap simbol non-terminal dalam sintaksanya.
  Tetapi mereka tidak dapat menangani dengan sintaks konteks-sensitif . Misalnya ketika Anda memiliki ekspresi x+3dan dalam satu konteks ini xbisa menjadi nama variabel, dan dalam konteks lain itu bisa menjadi nama fungsi dll.

• Level 1: Tata bahasa yang sensitif terhadap konteks

• Level 0: Tata bahasa tidak terbatas
  Disebut juga tata bahasa enumerable rekursif.

Ya, mereka sangat berbeda dalam teori, dan dalam implementasi.

Lexers digunakan untuk mengenali "kata-kata" yang membentuk elemen bahasa, karena struktur kata-kata tersebut umumnya sederhana. Ekspresi reguler sangat bagus dalam menangani struktur yang lebih sederhana ini, dan ada mesin pencocokan ekspresi reguler berkinerja tinggi yang digunakan untuk mengimplementasikan lexer.

Parser digunakan untuk mengenali "struktur" frasa bahasa. Struktur seperti itu umumnya jauh melampaui apa yang bisa dikenali oleh "ekspresi reguler", sehingga orang perlu parser "sensitif konteks" untuk mengekstraksi struktur tersebut. Parser peka konteks sulit dibangun, jadi kompromi tekniknya adalah menggunakan tata bahasa "bebas konteks" dan menambahkan retasan ke parser ("tabel simbol", dll.) Untuk menangani bagian peka konteks.

Baik teknologi lexing maupun parsing sepertinya tidak akan segera hilang.

Mereka dapat disatukan dengan memutuskan untuk menggunakan teknologi "parsing" untuk mengenali "kata", seperti yang saat ini dieksplorasi oleh parser GLR tanpa pemindai. Itu memiliki biaya runtime, karena Anda menerapkan mesin yang lebih umum untuk apa yang sering merupakan masalah yang tidak memerlukannya, dan biasanya Anda membayar untuk itu dalam overhead. Di mana Anda memiliki banyak siklus gratis, overhead itu mungkin tidak masalah. Jika Anda memproses banyak teks, maka overhead itu penting dan parser ekspresi reguler klasik akan terus digunakan.

Kapan cukup lexing, kapan Anda membutuhkan EBNF?

EBNF benar-benar tidak menambah banyak kekuatan tata bahasa. Ini hanya notasi kenyamanan / jalan pintas / "gula sintaksis" atas aturan tata bahasa Chomsky Normal Form (CNF) standar. Misalnya, alternatif EBNF:

S --> A | B

Anda dapat mencapainya di CNF hanya dengan mendaftar setiap produksi alternatif secara terpisah:

S --> A      // `S` can be `A`,
S --> B      // or it can be `B`.

Elemen opsional dari EBNF:

S --> X?

Anda dapat mencapai di CNF dengan menggunakan produksi yang dapat dibatalkan , yaitu yang dapat diganti dengan string kosong (dilambangkan dengan hanya produksi kosong di sini; yang lain menggunakan epsilon atau lambda atau lingkaran silang):

S --> B       // `S` can be `B`,
B --> X       // and `B` can be just `X`,
B -->         // or it can be empty.

Produksi dalam bentuk seperti yang terakhir di Batas disebut "penghapusan", karena dapat menghapus apa pun kepanjangan dari produksi lain (produk string kosong bukan yang lain).

Tidak ada atau lebih banyak pengulangan dari EBNF:

S --> A*

Anda dapat memperoleh dengan menggunakan produksi rekursif , yaitu, yang menanamkan sendiri di suatu tempat di dalamnya. Itu bisa dilakukan dengan dua cara. Yang pertama adalah rekursi kiri (yang biasanya harus dihindari, karena parser Keturunan Rekursif Top-Down tidak dapat menguraikannya):

S --> S A    // `S` is just itself ended with `A` (which can be done many times),
S -->        // or it can begin with empty-string, which stops the recursion.

Mengetahui bahwa itu hanya menghasilkan string kosong (akhirnya) diikuti oleh nol atau lebih A, string yang sama ( tetapi bukan bahasa yang sama! ) Dapat diekspresikan menggunakan rekursi kanan :

S --> A S    // `S` can be `A` followed by itself (which can be done many times),
S -->        // or it can be just empty-string end, which stops the recursion.

Dan ketika datang +untuk satu atau lebih pengulangan dari EBNF:

S --> A+

itu dapat dilakukan dengan memfaktorkan satu Adan menggunakan *seperti sebelumnya:

S --> A A*

yang bisa Anda ungkapkan dalam CNF seperti itu (saya menggunakan rekursi yang benar di sini; coba cari tahu sendiri yang lain sebagai latihan):

S --> A S   // `S` can be one `A` followed by `S` (which stands for more `A`s),
S --> A     // or it could be just one single `A`.

Mengetahui hal itu, Anda sekarang mungkin dapat mengenali tata bahasa untuk ekspresi reguler (yaitu, tata bahasa reguler ) sebagai yang dapat diekspresikan dalam produksi EBNF tunggal yang hanya terdiri dari simbol terminal. Secara umum, Anda dapat mengenali tata bahasa reguler ketika Anda melihat produksi yang mirip dengan ini:

A -->        // Empty (nullable) production (AKA erasure).
B --> x      // Single terminal symbol.
C --> y D    // Simple state change from `C` to `D` when seeing input `y`.
E --> F z    // Simple state change from `E` to `F` when seeing input `z`.
G --> G u    // Left recursion.
H --> v H    // Right recursion.

Artinya, hanya menggunakan string kosong, simbol terminal, non-terminal sederhana untuk penggantian dan perubahan keadaan, dan menggunakan rekursi hanya untuk mencapai pengulangan (iterasi, yang hanya rekursi linier - yang tidak bercabang seperti pohon). Tidak ada yang lebih maju di atas ini, maka Anda yakin itu adalah sintaksis biasa dan Anda bisa menggunakan hanya lexer untuk itu.

Tetapi ketika sintaks Anda menggunakan rekursi dengan cara yang tidak sepele, untuk menghasilkan struktur bersarang seperti pohon, mirip diri, seperti yang berikut ini:

S --> a S b    // `S` can be itself "parenthesized" by `a` and `b` on both sides.
S -->          // or it could be (ultimately) empty, which ends recursion.

maka Anda dapat dengan mudah melihat bahwa ini tidak dapat dilakukan dengan ekspresi reguler, karena Anda tidak dapat menyelesaikannya menjadi satu produksi EBNF dengan cara apa pun; Anda akan berakhir dengan mengganti Stanpa batas, yang akan selalu menambah as dan bs di kedua sisi. Lexers (lebih khusus: Finite State Automata yang digunakan oleh lexers) tidak dapat menghitung ke angka arbitrer (mereka terbatas, ingat?), Jadi mereka tidak tahu berapa banyak ayang ada untuk mencocokkan mereka secara merata dengan begitu banyak b. Tata bahasa seperti ini disebut tata bahasa bebas konteks (paling tidak), dan mereka membutuhkan parser.

Tata bahasa bebas konteks dikenal untuk diuraikan, sehingga mereka banyak digunakan untuk menggambarkan sintaks bahasa pemrograman. Tapi masih ada lagi. Kadang-kadang tata bahasa yang lebih umum diperlukan - ketika Anda memiliki lebih banyak hal untuk dihitung pada saat yang sama, secara mandiri. Misalnya, ketika Anda ingin mendeskripsikan bahasa di mana orang dapat menggunakan kurung bundar dan kurung kurawal, tetapi mereka harus dipasangkan dengan benar satu sama lain (kurung kurawal dengan kurawal, bundar dengan putaran). Tata bahasa semacam ini disebut konteks-sensitif . Anda dapat mengenalinya dengan memiliki lebih dari satu simbol di sebelah kiri (sebelum panah). Sebagai contoh:

A R B --> A S B

Anda dapat menganggap simbol-simbol tambahan ini di sebelah kiri sebagai "konteks" untuk menerapkan aturan. Mungkin ada beberapa prasyarat, postconditions dll Sebagai contoh, aturan di atas akan menggantikan Rmenjadi S, tetapi hanya ketika itu dalam antara Adan B, meninggalkan mereka Adan Bdiri mereka sendiri tidak berubah. Sintaks semacam ini benar-benar sulit untuk diuraikan, karena membutuhkan mesin Turing yang lengkap. Ini keseluruhan cerita lain, jadi saya akan berakhir di sini.

Untuk menjawab pertanyaan sebagaimana ditanyakan (tanpa mengulangi apa yang muncul di jawaban lain)

Lexer dan parser tidak jauh berbeda, seperti yang disarankan oleh jawaban yang diterima. Keduanya didasarkan pada formalisme bahasa sederhana: bahasa reguler untuk lexers dan, hampir selalu, bahasa bebas konteks (CF) untuk parser. Keduanya terkait dengan model komputasi yang cukup sederhana, otomat keadaan terbatas dan otomat stack push-down. Bahasa reguler adalah kasus khusus bahasa bebas konteks, sehingga lexer dapat diproduksi dengan teknologi CF yang agak lebih kompleks. Tapi itu bukan ide yang baik karena setidaknya ada dua alasan.

Poin mendasar dalam pemrograman adalah bahwa komponen sistem harus dilengkapi dengan teknologi yang paling tepat, sehingga mudah diproduksi, dipahami, dan dipelihara. Teknologi ini tidak boleh berlebihan (menggunakan teknik yang jauh lebih kompleks dan mahal daripada yang dibutuhkan), juga tidak boleh berada pada batas kekuatannya, sehingga membutuhkan kontraksi teknis untuk mencapai tujuan yang diinginkan.

Itu sebabnya "Tampaknya modis untuk membenci ekspresi reguler". Meskipun mereka dapat melakukan banyak hal, mereka kadang-kadang membutuhkan pengkodean yang sangat tidak dapat dibaca untuk mencapainya, belum lagi fakta bahwa berbagai ekstensi dan pembatasan dalam implementasi agak mengurangi kesederhanaan teoretis mereka. Lexers biasanya tidak melakukan itu, dan biasanya teknologi yang sederhana, efisien, dan tepat untuk menguraikan token. Menggunakan parser CF untuk token akan berlebihan, meskipun itu mungkin.

Alasan lain untuk tidak menggunakan formalisme CF untuk lexers adalah bahwa mungkin tergoda untuk menggunakan kekuatan CF penuh. Tapi itu mungkin menimbulkan masalah struktural terkait pembacaan program.

Pada dasarnya, sebagian besar struktur teks program, dari mana makna diekstraksi, adalah struktur pohon. Ini mengungkapkan bagaimana kalimat parse (program) dihasilkan dari aturan sintaksis. Semantik diturunkan oleh teknik komposisi (homomorfisme untuk yang berorientasi matematis) dari cara aturan sintaksis disusun untuk membangun pohon parse. Karena itu struktur pohon sangat penting. Fakta bahwa token diidentifikasi dengan lexer berbasis set reguler tidak mengubah situasi, karena CF yang dikomposisi dengan regular masih memberikan CF (saya berbicara sangat longgar tentang transduser reguler, yang mengubah aliran karakter menjadi aliran token).

Namun, CF yang dikomposisikan dengan CF (melalui transduser CF ... maaf untuk matematika), tidak selalu memberikan CF, dan mungkin membuat segalanya lebih umum, tetapi kurang bisa ditelusuri dalam praktik. Jadi CF bukan alat yang tepat untuk lexers, meskipun bisa digunakan.

Salah satu perbedaan utama antara reguler dan CF adalah bahasa reguler (dan transduser) sangat baik menyusun dengan hampir semua formalisme dalam berbagai cara, sementara bahasa CF (dan transduser) tidak, bahkan dengan diri mereka sendiri (dengan beberapa pengecualian).

(Perhatikan bahwa transduser reguler dapat digunakan orang lain, seperti formalisasi beberapa teknik penanganan kesalahan sintaksis.)

BNF hanyalah sintaks khusus untuk menyajikan tata bahasa CF.

EBNF adalah gula sintaksis untuk BNF , menggunakan fasilitas notasi reguler untuk memberikan versi tersier tata bahasa BNF. Itu selalu dapat diubah menjadi BNF murni yang setara.

Namun, notasi reguler sering digunakan dalam EBNF hanya untuk menekankan bagian sintaksis yang sesuai dengan struktur elemen leksikal, dan harus dikenali dengan lexer, sedangkan sisanya dengan agak disajikan dalam BNF lurus. Tapi itu bukan aturan mutlak.

Sebagai rangkuman, struktur token yang lebih sederhana lebih baik dianalisis dengan teknologi bahasa biasa yang lebih sederhana, sedangkan struktur bahasa yang berorientasi pohon (sintaksis program) lebih baik ditangani oleh tata bahasa CF.

Saya sarankan juga melihat jawaban AHR .

Tapi ini meninggalkan pertanyaan terbuka: Mengapa pohon?

Pohon adalah dasar yang baik untuk menentukan sintaksis karena

• mereka memberikan struktur sederhana pada teks

• ada sangat mudah untuk menghubungkan semantik dengan teks berdasarkan struktur itu, dengan teknologi yang dipahami secara matematis (komposisionalitas melalui homomorfisme), seperti ditunjukkan di atas. Ini adalah alat aljabar dasar untuk mendefinisikan semantik formalisme matematika.

Oleh karena itu itu adalah representasi perantara yang baik, seperti yang ditunjukkan oleh keberhasilan Pohon Sintaksis Abstrak (AST). Perhatikan bahwa AST sering berbeda dari parse tree karena teknologi parsing yang digunakan oleh banyak profesional (seperti LL atau LR) hanya berlaku untuk subset tata bahasa CF, sehingga memaksa distorsi tata bahasa yang kemudian diperbaiki di AST. Ini dapat dihindari dengan teknologi parsing yang lebih umum (berdasarkan pemrograman dinamis) yang menerima tata bahasa CF.

Pernyataan tentang fakta bahwa bahasa pemrograman lebih sensitif terhadap konteks (CS) daripada CF adalah arbitrer dan dapat diperdebatkan.

Masalahnya adalah bahwa pemisahan sintaksis dan semantik adalah arbitrer. Memeriksa deklarasi atau jenis perjanjian dapat dilihat sebagai bagian dari sintaks, atau bagian dari semantik. Hal yang sama berlaku untuk gender dan kesepakatan angka dalam bahasa alami. Tetapi ada bahasa-bahasa alami di mana kesepakatan jamak bergantung pada makna kata semantik yang sebenarnya, sehingga tidak cocok dengan sintaksis.

Banyak definisi bahasa pemrograman dalam semantik denotasi menempatkan deklarasi dan ketik pengecekan dalam semantik. Jadi menyatakan seperti yang dilakukan oleh Ira Baxter bahwa parser CF sedang diretas untuk mendapatkan sensitivitas konteks yang diperlukan oleh sintaksis terbaik adalah pandangan sewenang-wenang tentang situasi. Ini mungkin diatur sebagai retasan dalam beberapa kompiler, tetapi tidak harus demikian.

Juga bukan hanya pengurai CS (dalam arti yang digunakan dalam jawaban lain di sini) sulit untuk dibuat, dan kurang efisien. Mereka juga tidak cukup untuk mengekspresikan dengan jelas bagian dari konteks-sensitivitas yang mungkin diperlukan. Dan mereka tidak secara alami menghasilkan struktur sintaksis (seperti parse-tree) yang nyaman untuk menurunkan semantik program, yaitu untuk menghasilkan kode yang dikompilasi.

Ada beberapa alasan mengapa bagian analisis kompiler biasanya dipisahkan menjadi fase analisis leksikal dan parsing (analisis sintaksis).

1. Kesederhanaan desain adalah pertimbangan terpenting. Pemisahan analisis leksikal dan sintaksis seringkali memungkinkan kita untuk menyederhanakan setidaknya satu dari tugas-tugas ini. Sebagai contoh, parser yang harus berurusan dengan komentar dan spasi sebagai unit sintaksis. Jauh lebih kompleks daripada yang dapat mengasumsikan komentar dan ruang putih telah dihapus oleh penganalisa leksikal. Jika kita merancang bahasa baru, memisahkan masalah leksikal dan sintaksis dapat menyebabkan desain bahasa yang lebih bersih secara keseluruhan.
2. Efisiensi penyusun ditingkatkan. Alat analisis leksikal yang terpisah memungkinkan kita untuk menerapkan teknik khusus yang hanya melayani tugas leksikal, bukan pekerjaan parsing. Selain itu, teknik buffering khusus untuk membaca karakter input dapat mempercepat kompiler secara signifikan.
3. Portabilitas kompiler ditingkatkan. Keunikan khusus perangkat input dapat dibatasi untuk penganalisa leksikal.

resource___ Compiler (Edisi ke-2) ditulis oleh- Alfred V. Abo University Columbia Monica S. Lam Stanford University Ravi Sethi Avaya Jeffrey D. Ullman Stanford University