Bahasa pemrograman praktis non-teoretis apa yang tidak memiliki kata kunci yang dipesan?


22

Saya telah mencari bahasa pemrograman praktis yang tidak memiliki kata kunci yang dicadangkan, tetapi saya belum beruntung menemukannya.

Saya sedang mengerjakan bahasa pemrograman untuk perbaikan dan hiburan saya sendiri dan saya belum perlu memasukkan kata kunci apa pun, itulah yang mendorong saya untuk mencari dan pertanyaan:

Saya tidak melihat kemudahan bagi penulis kompiler sebagai hal penting bagi pengguna akhir bahasa. Komputer sekarang cukup kuat untuk dapat menyimpulkan makna dari konteks. Tidak lebih dari seorang penulis perlu memberi label pada kata benda, kata kerja dan semacamnya saat menulis novel, mengapa seorang programmer harus memberi label fungsi dan variabel dengan function x() {}atau set x = 1atau var x = 1dll; ketika saya dapat menyimpulkan dari konteks pernyataan bahwa itu adalah deklarasi fungsi atau doa atau bahwa label adalah tugas untuk nilai atau referensi ke nilai label?

Berikut ini adalah contoh nyata dari apa yang dilakukan parser saya saat ini, tidak perlu kata kunci yang dipesan untuk mendukung hal-hal umum yang biasanya memiliki banyak suara seperti funcatau functionatau decatau tidak.

Deklarasi Fungsi

sum3(a,b,c) -> a + b + c.

Doa Fungsi

x = sum3(1,2,3).

Bernama Fungsi Anonim x

x = (a,b,c) -> a + b + c.
y = x(1,2,3).

Saya ingin tahu mengapa kata kunci yang penting untuk bahasa pemrograman yang sukses?


8
Keempat cukup praktis, dan tidak memiliki kata kunci.
SK-logic

4
@ JamesAnderson, tidak, itu hanya kata-kata, sama seperti semua kata lainnya. Tidak ada arti khusus apa pun.
SK-logic

7
Apakah operator dan tanda baca dianggap sebagai "kata kunci"? jika ya, maka tidak ada bahasa yang ada, karena tidak ada sintaks yang dapat didefinisikan.
Emilio Garavaglia

2
@ SK-logic: biasanya. Tapi apa "pengidentifikasi" jika Anda belum melakukan tokenize? Karena token adalah "sengatan apa pun yang dapat dikenali", "int", "myvalue" dan "+" tidak berbeda, sebelum aturan sintaks diberikan. Jika "+" tidak didefinisikan sebagai operator, itu bisa saja nama untuk hal seperti string karakter tunggal unicode lainnya. Operator, berdasarkan sudut pandang sintaksis murni, tidak lebih dari "kata kunci karakter tunggal".
Emilio Garavaglia

2
Dalam konteks ini, apa itu kata kunci? Apakah ini pengidentifikasi yang memiliki arti khusus untuk kompiler? Apakah ini merupakan pengidentifikasi yang tidak boleh digunakan oleh programmer sebagai variabel atau sesuatu? Apakah ini dianggap tanpa kata kunci jika kata kunci harus ditentukan secara khusus? (Beberapa waktu yang lalu saya melihat sistem ALGOL di mana kata kunci perlu dikutip menjadi kata kunci.)
David Thornley

Jawaban:


12

MUMPS sangat sukses, digunakan secara luas dalam asuransi dan perawatan kesehatan dan tidak memiliki kata-kata cadangan. Saya akan mengatakan mereka membantu dalam hal menulis kode yang lebih jelas tetapi mereka tidak sepenuhnya diperlukan. APL adalah contoh lain. APL melihat digunakan untuk skrip satu kali di Industri Nuklir antara lain. J , anggota keluarga APL juga tidak memiliki kata kunci.

Kata kunci membantu penulis kompiler menerapkan parsing lebih mudah. APL terkenal asosiatif yang benar. Mereka juga membantu memperkuat konvensi dan meningkatkan keterbacaan. APL tidak dikenal karena sangat mudah dibaca oleh kebanyakan orang.


2
+1 untuk "Kata kunci membantu penulis kompiler menerapkan parsing lebih mudah". Saya pikir itu sudah cukup. Kata kunci diciptakan untuk mengurangi jumlah konteks yang harus disimpan oleh parser, ketika seluruh kompiler plus set kerjanya harus masuk ke dalam selusin RAM RAM.
Jörg W Mittag

2
Lebih mudah untuk menulis parser untuk APL daripada hampir semua bahasa lain! Pertimbangkan bahwa implementasi pertama penerjemah APL dilakukan menggunakan transistor dan dioda.
James Anderson

2
Saya pikir alasan utama kata kunci adalah untuk membuatnya lebih mudah bagi manusia untuk mengurai bahasa lebih mudah. Komputer akan lebih bahagia jika bahasanya seluruhnya terdiri dari angka dan pola bit seperti kode mesin mereka.
James Anderson

6
Apa kekurangan APL dalam kata kunci, itu lebih dari make-up dalam membutuhkan font sendiri.
Blrfl

@ Blrfl Itulah inti dari J, K, dan Q. Mereka semua satu tingkat atau lebih, APL di ASCII.
Insinyur Dunia

9

Salah satu bahasa yang terkenal tanpa kata kunci adalah Lisp. Hal yang paling dekat dengan kata kunci disebut bentuk khusus - jumlah mereka dapat bervariasi di antara dialek - yang mendapat perlakuan khusus dari penerjemah. Terlepas dari itu mereka tidak dapat dibedakan dari fungsi biasa dalam hal jika mereka digunakan, dengan pengecualian bahwa mereka tidak dapat didefinisikan ulang (setidaknya dalam Lisps saya kenal).

Ini menghasilkan sintaks yang sederhana (tetapi paren-berat), dan merupakan salah satu hal yang memungkinkan Lisp memiliki sistem makro yang kuat. Di sisi lain, Lisp sering dikatakan sulit dibaca. APL dan MUMPS, terlebih lagi, saya telah melihat keduanya digambarkan setengah jalan ke Brainf * ck. Kata kunci memang membantu di departemen ini dan membuat membaca kode lebih mudah bagi kita manusia juga.

Jadi saya tidak akan mengatakan kata kunci diperlukan untuk bahasa yang sukses, tetapi mereka pasti membantu bahasa untuk menjadi sukses.


1
IIRC Lisp tidak memiliki kata kunci. Bentuk khusus harus diperlakukan secara khusus oleh kompiler, tetapi namanya adalah simbol biasa.
Jan Hudec

2
Kata kunci adalah fitur sintaksis, yang tidak dimiliki Lisp. Saya pikir tidak masuk akal untuk berbicara tentang kata kunci di Lisp, sungguh.
Jörg W Mittag

2
Saya setuju dengan Jörg. Saya pikir orang dapat berbicara tentang kata kunci ketika suatu bahasa memiliki token yang harus didefinisikan secara eksplisit sebagai khusus untuk dibedakan dari token dengan struktur yang sama. Token yang berbeda mengarah ke pohon sintaks yang berbeda. Misalnya, ifdalam C akan menjadi pengidentifikasi yang valid jika tidak didefinisikan sebagai khusus (kata kunci). Ini berarti bahwa ifitu bukan pengidentifikasi dan if = 10memberikan kesalahan sintaksis. Jika saya tidak salah, sintaks minimal Lisp ini tidak membedakan defundari f, x, ydan +di (defun f (x y) (+ x y)).
Giorgio

@Giorgio terutama if adalah nama variabel yang valid dalam Common Lisp (dan Lisp-2s lainnya) (defparameter if nil)tidak akan merusak apa pun dan dapat digunakan dalam bentuk seperti(unless if (setf if t))
tobyodavies

Namun, pada catatan yang sama, (defun if ...)akan gagal. Mengambil catatan dari komentar ke akun dan mengedit jawabannya. Saya dapat setuju bahwa formulir khusus bukan kata kunci pada tingkat yang sama seperti di C misalnya, masih mereka yang paling dekat dengan Lisp.
scrwtp

8

TCL tidak memiliki kata kunci, dan memang hanya 12 aturan sintaksis. sementara itu tidak sepopuler dulu, ia memiliki ceruk dengan harapan dan tertanam dalam ECAD dan router sehingga tentu dianggap sebagai praktis untuk pikiran saya.

Saya juga berpikir itu mungkin menunjukkan mengapa banyak bahasa tidak mengikuti rute ini. Ya sangat mungkin untuk menulis parser TCL (bisa dibilang lebih mudah daripada banyak bahasa lain) namun Anda tidak dapat menulis tata bahasa BNF yang sangat berguna untuk bahasa tersebut dan banyak orang tampaknya kesulitan mempelajari bahasa tersebut. Saya menduga ini setidaknya sebagian karena kurangnya kata kunci.


2
Tcl sangat mirip dengan Lisp dalam hal ini, kecuali alih-alih "semuanya adalah daftar" ia memiliki "semuanya adalah string". Daftar hanya string dengan spasi putih di dalamnya dan pemanggilan prosedur hanya daftar yang elemen pertamanya ditafsirkan sebagai nama prosedur dan sisanya ditafsirkan sebagai argumennya. Itu pada dasarnya adalah Lisp S-Expression.
Jörg W Mittag

ya mereka berdua menggunakan notasi Polandia dan homo-ikon sehingga memiliki semantik yang sangat mirip
jk.

5

Komputer sekarang cukup kuat untuk dapat menyimpulkan makna dari konteks.

Apakah ini berarti Anda menginginkan tata bahasa yang tidak bebas konteks? Semoga berhasil.

Itu bukan pertanyaan tentang menjadi kuat atau tidak. Ada aturan abadi tentang bahasa yang tidak berubah - aturan matematika. Ini, dan fakta bahwa bahasa pemrograman harus mudah secara sintaksis akan membuat aturan CFG untuk beberapa dekade mendatang.

Btw., Di Haskell seperti sintaks, Anda hanya menulis sesuatu seperti

f x y = (x+1)*(y-1)

untuk mendefinisikan suatu fungsi. Tetapi perhatikan bahwa "kata kunci" dalam hal ini adalah '='. Jika Anda melewatkannya, hal-hal buruk akan terjadi di parser.

Tapi ini adalah titik di mana saya setuju dengan Anda, saya menemukan ini jauh lebih intuitif daripada semua kata kunci def, dcl, fun, fn, function atau what-not yang memperkenalkan fungsi dalam bahasa lain.

Namun, tata bahasa ini dapat ditulis dalam LALR tua sederhana (1), tidak ada makna yang "disimpulkan dari konteks" di sini.


1
+1 untuk mengatasi pernyataan ini (Komputer sekarang cukup kuat untuk dapat menyimpulkan makna dari konteks). Saya pikir alasan mengapa tata bahasa CFG lebih disukai adalah bahwa mereka memungkinkan struktur program untuk didefinisikan secara induktif. Saya tidak mengerti mengapa seseorang ingin mengubah ini bahkan dalam 100 tahun, mungkin saya hanya kurang imajinasi?
Giorgio

2
CFG sangat mati, dan telah mati selama beberapa dekade. JavaScript di dalam HTML, bahkan string format C di dalam C, bahkan komentar bersarang di, katakanlah, OCaml - semua hal ini tidak bebas konteks. Dan, mengapa Anda ingin membatasi diri pada formalisme pilihan yang sewenang-wenang, sekarang, di zaman PEG dan GLR?
SK-logic

1
@Ingo, ya, Anda benar, pilihan contoh yang salah. Maksud saya tata bahasa campuran dan dapat diperpanjang (yaitu, orde tinggi), yang bukan CFG.
SK-logic

2
@ SK-logic: Saya tidak tahu dari mana Anda mendapat informasi bahwa CFG itu sudah mati. Saya telah berbicara dengan seorang mantan kolega saya yang telah mengajar konstruksi compiler selama 20 tahun terakhir dan CFG tampaknya jauh dari kematian.
Giorgio

1
@ Ingo: Sejauh yang saya ingat, aspek non CF ditangani setelah itu dengan menganalisis pohon parsing secara semantik. Misalnya, { int x = 0; x = "HELLO"; }harus menghasilkan pohon parse tetapi ketika kompiler mencari x dalam tugas kedua ia melihat bahwa ia telah dinyatakan sebagai int dan mengeluarkan kesalahan ketik. Jadi program ditolak bahkan jika struktur CF-nya benar.
Giorgio

4

Sejauh yang saya tahu, Smalltalk adalah bahasa yang memiliki kata kunci paling sedikit (jika saya tidak menghitung bahasa seperti Brainfuck). Smalltalk kata kunci true, false, nil, self, superdan thisContext.

Saya telah mendesain bahasa, terinspirasi dengan smalltalk, yang tidak memiliki kata kunci. Tetapi setelah beberapa waktu menggunakannya saya akhirnya menambahkan beberapa kata kunci, sebagian besar untuk gula sintaksis.

Jadi, pendapat saya adalah bahwa bahasa tanpa kata kunci adalah mungkin, tetapi itu tidak terlalu praktis dan itulah alasan mengapa semua bahasa populer memiliki kata kunci.


Jika Smalltalk memiliki dukungan untuk pengiriman pesan dengan penerima implisit, maka setidaknya true, falsedan nildapat didefinisikan sebagai metode pada penerima implisit itu, dan, mengingat kemampuan refleksi, tiga lainnya mungkin juga.
Jörg W Mittag

1
Itu bukan kata kunci, itu pseudovariabel. "Pseudo" karena true, falsedan nilmerupakan nilai-nilai terkenal yang disediakan oleh lingkungan dan self, superdan thisContextmerupakan variabel yang tidak dapat Anda tetapkan tetapi nilainya berubah akibat eksekusi.
Frank Shearar

3

Anda tampaknya bekerja di bawah asumsi yang salah, bahwa ada kata kunci untuk mempermudah kompilator. Walaupun mereka membuat segalanya lebih mudah bagi kompiler, mereka memiliki manfaat yang jauh lebih penting: mereka membuat segalanya lebih mudah bagi orang yang membaca kode .

Ya, Anda bisa melihat sekelompok konteks dan mencari tahu bahwa Anda sedang melihat deklarasi fungsi atau deklarasi variabel, tetapi tergantung pada konteks dan kompleksitas kode yang terlibat, yang bisa memakan waktu lama untuk mencari tahu . Atau, Anda dapat memiliki kata kunci yang berguna di sana seperti function atau var , dan Anda segera tahu apa yang Anda lihat.

Ya, mereka membuat kode lebih rumit untuk ditulis , tetapi mengingat bahwa program menghabiskan lebih banyak waktu dalam pemeliharaan daripada dalam produksi, dan bahwa kode mereka dibaca, diperdebatkan dan dipelihara lebih banyak daripada yang dibuat, mencoba merancang bahasa Anda untuk membuatnya mudah untuk menulis daripada mudah dibaca adalah kasus klasik dari optimasi prematur yang berbahaya.

Juga, jangan meremehkan konsep yang membuat pekerjaan kompiler lebih mudah. Semakin mudah mengurai, semakin cepat kode Anda dikompilasi, yang berarti siklus edit-build-debug semakin cepat, yang berarti produktivitas Anda naik.

Ketika Anda memiliki basis kode yang besar dan kompleks, itu bisa menghasilkan perbedaan produktivitas yang tidak sepele. Misalnya, tempat saya bekerja, kami memiliki program di tempat kerja yaitu sekitar 4 juta baris Delphi. Kami memiliki modul lain yang sekitar 300.000 baris C ++. Keduanya membutuhkan waktu yang sama untuk dikompilasi. (Sekitar 3 menit.) Jika kami memiliki 4 juta baris C ++, mungkin diperlukan satu jam untuk membuatnya!


Semua poin bagus. +1

jika setiap kata benda, kata kerja, kata kerja dan kata sifat dalam sebuah novel diberi label seperti itu akan membuatnya LEBIH KERAS untuk dibaca tidak mudah!

@JarrodRoberson: Tentu saja, tapi kode bukan novel. Bahasa alami sangat berbeda dari bahasa pemrograman. Bahasa alami dipahami secara intuitif, sedangkan bahasa pemrograman memiliki semantik formal. Teknik yang digunakan untuk membacanya dan memahami maknanya sangat berbeda, dan merupakan kesalahan untuk menyamakan keduanya seperti yang Anda lakukan.
Mason Wheeler

Saya mengatakan penulis kompiler yang berbeda dari kompiler . Kompiler menjadi lebih cepat pada perangkat keras yang lebih cepat, penulis kompiler adalah manusia, kami tidak mematuhi Hukum Moore!

basis kode yang cenderung saya kerjakan adalah urutan besarnya lebih panjang dari panjang novel, kebanyakan> 1.000.000+ baris kode, sebagian besar novel terpanjang adalah <2.000.000 kata ! Dan seperti novel yang dibaca oleh manusia, sebenarnya lebih banyak waktu dihabiskan membaca kode daripada menulisnya! Diberikan basis kode yang> 10 tahun dan 1.000.000+ baris berapa kali ini dibaca oleh pengembang lebih dari 10 tahun, katai waktu yang diperlukan untuk membuat di tempat pertama.!

2

Ada beberapa contoh langka.

APL hanya menggunakan simbol - tetapi banyak dari mereka! Anda memerlukan keyboard khusus untuk menggunakan bahasa tersebut.

Lihat artikel wikipedia ini

CORAL 66 - memiliki kata kunci tetapi hanya mengenalinya jika dikutip dengan tanda kutip tunggal.

PL / 1 juga memiliki kata kunci - tetapi Anda juga dapat menggunakannya sebagai nama variabel atau prosedur.

Secara keseluruhan pertanyaan Anda sedikit seperti menanyakan "mengapa bahasa yang digunakan memiliki kata-kata?".


Hanya menambahkan bahwa jika Anda menyukai tampilan APL tetapi tidak ingin membeli keyboard baru, maka J adalah masalahnya.
AakashM

0

Alasan utamanya adalah lebih mudah bagi manusia dan komputer untuk menguraikan. Membedakan bahasa yang rumit tanpa kata kunci akan membutuhkan banyak simbol sebagai sintaksis, dan itu akan membingungkan secara besar-besaran dan tidak perlu. Jauh lebih mudah dibaca functiondaripada $!{}. Dan konteks tidak menyelesaikan semua ambiguitas.


1
Saya pikir kata kunci dalam jawaban Anda adalah kompleks , bahasa yang dirancang cukup harus sederhana , bukan kompleks .

1
@Jarrod Roberson: Leonardo da Vinci: "Kesederhanaan adalah kecanggihan tertinggi", Antoine de Saint Exupéry: "Tampaknya kesempurnaan tercapai bukan ketika tidak ada yang tersisa untuk ditambahkan, tetapi ketika tidak ada lagi yang tersisa untuk diambil".
Giorgio

1
@Jarrod: Semua bahasa komputer yang bermakna ekspresif kompleks.
DeadMG

1
@DeadMG: Skema sangat sederhana dan pada saat yang sama sangat ekspresif. Sayangnya, sejauh yang saya tahu tidak memiliki perpustakaan standar.
Giorgio

Erlang sangat ekspresif dan tidak rumit secara sintaksis. Saya pikir semua bahasa fungsional akhirnya menjadi lebih ekspresif dengan kata kunci yang kurang dicadangkan.
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.