Mengapa fleksibilitas Forth membuat tata bahasa tidak pantas untuk itu?


10

Saya baru-baru ini melakukan tugas menulis bahasa pemrograman berbasis stack. Sebelum saya mulai mendesain bahasa saya, saya pikir akan lebih baik untuk membaca dan bereksperimen dengan bahasa berbasis stack yang ada.

Ini membawa saya ke topik posting ini. Saya membaca artikel Wikipedia tentang Forth , bahasa berbasis tumpukan yang menggunakan ekspresi gaya postfix. Dalam artikel itu, saya melihat pernyataan berikut:

Fleksibilitas Forth membuat tata bahasa BNF statis tidak pantas, dan tidak memiliki kompiler monolitik. Memperluas kompiler hanya membutuhkan penulisan kata baru, alih-alih memodifikasi tata bahasa dan mengubah implementasi yang mendasarinya.

Dari pemahaman saya, dalam istilah Forth, istilah "kata" tampaknya pada dasarnya identik dengan "subrutin". Mengingat hal ini, pernyataan di atas tampak aneh. Mengapa tepatnya kemampuan untuk membuat fungsi-fungsi baru di Forth membuat tata bahasa formal untuk Forth tidak pantas? Mengapa Anda perlu menulis ulang tata bahasa untuk setiap subrutin baru yang Anda tentukan? Bagaimana cara menulis kata baru di lingkungan merupakan perpanjangan dari kompiler? Pernyataan di atas tampaknya mirip dengan mengatakan bahwa tata bahasa formal tidak pantas untuk Python karena Anda dapat mendefinisikan fungsi baru.

Bahkan, saya memutuskan untuk mencoba menulis tata bahasa gaya BNF untuk bagian sederhana dari Forth di bawah ini:

program        ::= stmt+
stmt           ::= func | expr
func           ::= ':' expr+ ';'
expr           ::= INTEGER | word
word           ::= ('+' | '-' | '*' | '/' )

Tata bahasa di atas tampaknya mencakup subset yang valid dari pernyataan Forth, dan tampaknya tidak sulit untuk diperluas untuk mencakup semua pernyataan yang valid dalam bahasa Forth. Lebih jauh, jika parser kompiler mengimplementasikan tata bahasa di atas, saya gagal melihat bagaimana kompiler akan diperluas. Kompiler hanya akan menambahkan kata-kata baru ke lingkungannya . Hanya lingkungan yang diubah. Hampir tampak seolah-olah kutipan di atas dari Wikipedia menyatukan kode garis bawah yang menyusun kompiler (yang tidak berubah) dengan lingkungan kompiler (yang memang berubah).

Singkatnya, mengapa kebohongan Forth untuk mendefinisikan kata-kata baru (subrutin) membuat tidak pantas untuk tata bahasa tertulis?


1
"Tidak pantas" adalah kata yang kuat dalam konteks ini. Kata yang lebih baik mungkin akan "tidak perlu."
Robert Harvey

1
Oh, oke @RobertHarvery. Namun, jika itu masalahnya, maka kutipan yang saya kutip tampaknya akan berlaku untuk sebagian besar bahasa. Secara teknis, tata bahasa tidak pernah dibutuhkan , tetapi senang memilikinya - terutama ketika parser tulisan tangan.
Christian Dean

Namun dalam sebagian besar bahasa, parser bukanlah pustaka runtime sederhana yang dapat diubah oleh kode pengguna, sehingga memengaruhi cara baris berikutnya diuraikan.
Jörg W Mittag

Jawaban:


10

Kata "normal" cukup banyak hanya subrutin.

... tetapi Anda dapat menulis kata yang ditentukan pengguna , yang mengubah cara kerja kompiler. Misalnya, definisi biasanya dimulai dengan titik dua (":") dan diakhiri dengan tanda titik koma (";"). Tetapi jika Anda mau, Anda dapat (misalnya) mengubah apa yang dilakukan titik dua, dan dalam proses mengubah cara definisi kata "dikompilasi", sehingga mengubah cara kerja kompiler, dan mengubah tata bahasa bahasa yang dikenali.

Inilah sebabnya mengapa mengatakan tata bahasa tidak tepat - tata bahasa secara harfiah dapat berubah dari satu bagian program ke yang lain. Memuat kamus tidak hanya dapat mengubah subrutin yang namanya dikenali, tetapi juga tata bahasa yang diuraikan saat Anda mendefinisikan kata baru.


2
Apakah Anda yakin properti Forth ini benar-benar mengubah tata bahasa dan bukan hanya semantiknya?
Doc Brown

@DocBrown: Kebanyakan orang yang menggunakan Forth sangat menyukainya, jadi mereka biasanya hanya membuat perubahan minimal yang diperlukan untuk tugas yang sedang dikerjakan. Seseorang yang cukup ambisius (dan gila) dapat mengubah sintaks sepenuhnya jika mereka mau - seperti menggunakan notasi infiks alih-alih postfix, jika mereka ingin cukup buruk.
Jerry Coffin

@DocBrown Tata bahasa macam apa yang bisa Anda tulis yang memungkinkan saya menulis juru bahasa C di Forth, dan tiba-tiba beralih ke huruf C di tengah-tengah program?
user253751

@immibis: well, pertanyaan saya adalah - apakah Forth benar-benar mengizinkan sesuatu seperti ini? Dari artikel yang ditautkan itu, hal ini secara inheren tidak jelas bagi saya.
Doc Brown

@DocBrown Ya itu. Anda dapat menjalankan kode Anda pada waktu kompilasi, itu artinya jika Anda ingin, Anda dapat sepenuhnya mengambil alih kompilator. Pada dasarnya Anda dapat menjalankan compiler / interpreter C Anda di tengah-tengah compiler / interpreter Forth. (apakah Anda ingin akhirnya kembali ke Forth atau tidak, itu terserah Anda)
user253751

3

Di Keempat, Anda dapat menjalankan kode pada waktu kompilasi.

Secara khusus, Anda dapat menjalankan kode yang menggunakan kata-kata dari input. Misalnya, Anda bisa menulis kompiler C di Forth, dan kemudian memanggilnya pada waktu kompilasi, dan kemudian menulis sisa program Anda dalam C.

Lebih umum, Anda dapat menentukan kata-kata yang membaca argumen dari kode sumber. Secara tradisional Anda akan membaca kata-kata dengan cara yang sama seperti yang dilakukan kompiler, tetapi itu tidak diperlukan.

Misalnya, ."kata (yang mencetak string) tidak membaca hingga spasi berikutnya, ia membaca hingga yang berikutnya ". Jika Anda mencoba mem-parsing kode : PRINTHELLO ." Hello ; : func2 world!" ;tanpa case khusus untuk .", Anda akan menemukan bahwa itu tidak diurai dengan benar.

Anda pasti dapat menambahkan kasus khusus untuk ."untuk tata bahasa Anda, tapi tata bahasa masih akan salah jika programmer mendefinisikan kata-kata mereka sendiri seperti ."- misalnya inilah satu: : MY_PRINT POSTPONE ." ; IMMEDIATE. Kata ini setara dengan ."; Saya bisa menulis MY_PRINT Hello ; world! "dan tata bahasa Anda harus bisa menguraikannya. Semoga beruntung dengan itu.

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.