Những gì ngôn ngữ lập trình thực tế, không lý thuyết không có từ khóa dành riêng?


22

Tôi đã tìm kiếm một ngôn ngữ lập trình thực tế không có từ khóa dành riêng nhưng tôi không có may mắn tìm được một ngôn ngữ.

Tôi đang làm việc với một ngôn ngữ lập trình cho việc chỉnh sửa và giải trí của riêng tôi và tôi chưa cần đưa vào bất kỳ từ khóa nào, đó là điều dẫn tôi đến tìm kiếm của tôi và câu hỏi:

Tôi không thấy sự thuận tiện cho người viết trình biên dịch là quan trọng đối với người dùng cuối của ngôn ngữ. Máy tính đủ mạnh ngày nay để có thể suy ra ý nghĩa từ ngữ cảnh. Không hơn một nhu cầu nhà văn để danh từ nhãn, động từ và như vậy khi viết một cuốn tiểu thuyết, lý do tại sao một lập trình viên nên có chức năng nhãn và các biến với function x() {}hoặc set x = 1hoặc var x = 1vv; khi tôi có thể suy ra từ ngữ cảnh của các tuyên bố rằng đó là một khai báo hàm hoặc một lời gọi hoặc một nhãn là một sự gán cho một giá trị hoặc một tham chiếu đến giá trị nhãn đó?

Dưới đây là một ví dụ cụ thể về những gì trình phân tích cú pháp hiện tại của tôi đang làm, không cần các từ khóa dành riêng để hỗ trợ những thứ phổ biến thường có một loạt tiếng ồn như funchoặc functionhoặc deckhông.

Tuyên bố chức năng

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

Chức năng gọi

x = sum3(1,2,3).

Hàm ẩn danh có tên x

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

Tôi muốn biết tại sao các từ khóa quan trọng đối với một ngôn ngữ lập trình thành công?


8
Forth là khá thực tế, và nó không có bất kỳ từ khóa.
SK-logic

4
@JamesAnderson, không, chúng chỉ là những từ, giống như tất cả các từ khác. Không có ý nghĩa đặc biệt nào.
SK-logic

7
Các toán tử và dấu câu có được tính là "từ khóa" không? nếu có, thì không có ngôn ngữ nào có thể tồn tại, vì không có cú pháp nào có thể được định nghĩa.
Emilio Garavaglia

2
@ SK-logic: thông thường. Nhưng "định danh" là gì nếu bạn chưa token hóa? Vì mã thông báo là "bất cứ thứ gì có thể nhận ra", "int", "myvalue" và "+" không khác nhau, trước khi quy tắc cú pháp được đưa ra. Nếu "+" không được định nghĩa là toán tử, nó có thể chỉ là một tên cho một thứ giống như bất kỳ chuỗi ký tự đơn unicode nào khác. Các toán tử, theo quan điểm cú pháp thuần túy, không có gì khác hơn là "từ khóa ký tự đơn".
Emilio Garavaglia

2
Trong bối cảnh này, từ khóa là gì? Nó có phải là một định danh có ý nghĩa đặc biệt đối với trình biên dịch không? Đây có phải là một định danh mà lập trình viên không nên sử dụng như một biến hoặc một cái gì đó? Có tính là không có từ khóa nếu từ khóa phải được chỉ định đặc biệt? (Cách đây rất lâu tôi đã thấy một hệ thống ALGOL nơi các từ khóa cần được trích dẫn để trở thành từ khóa.)
David Thornley

Câu trả lời:


12

MUMPS rất thành công, được sử dụng rộng rãi trong bảo hiểm và chăm sóc sức khỏe và không có từ dành riêng. Tôi muốn nói rằng họ giúp đỡ trong việc viết mã rõ ràng hơn nhưng họ không thực sự cần thiết. APL là một ví dụ khác. APL thấy được sử dụng cho các kịch bản một lần trong ngành công nghiệp hạt nhân. J , một thành viên của gia đình APL cũng thiếu từ khóa.

Từ khóa giúp người viết trình biên dịch thực hiện phân tích cú pháp dễ dàng hơn. APL nổi tiếng là hiệp hội đúng. Họ cũng giúp củng cố các quy ước và cải thiện khả năng đọc. APL không được biết đến là rất dễ đọc với hầu hết.


2
+1 cho "Từ khóa giúp người viết trình biên dịch thực hiện phân tích cú pháp dễ dàng hơn". Tôi nghĩ đó là khá nhiều đó. Các từ khóa được phát minh để cắt giảm lượng ngữ cảnh mà trình phân tích cú pháp phải giữ trong bộ nhớ, trở lại khi toàn bộ trình biên dịch cộng với bộ làm việc của nó phải vừa với hàng tá KB RAM.
Jörg W Mittag

2
Thật dễ dàng để viết một trình phân tích cú pháp cho APL hơn hầu hết các ngôn ngữ khác! Hãy xem xét rằng việc thực hiện đầu tiên của trình thông dịch APL đã được thực hiện bằng cách sử dụng bóng bán dẫn và điốt.
James Anderson

2
Tôi nghĩ lý do chính cho các từ khóa là để giúp con người dễ dàng phân tích ngôn ngữ dễ dàng hơn. Máy tính sẽ hạnh phúc hơn nếu ngôn ngữ bao gồm hoàn toàn các số và mẫu bit giống như mã máy của chúng.
James Anderson

6
Những gì APL thiếu trong các từ khóa, nó nhiều hơn là bù vào việc yêu cầu phông chữ của riêng nó.
Blrfl

@Blrfl Đó là điểm của J, K và Q. Tất cả đều ở mức độ này hay mức độ khác, APL trong ASCII.
Kỹ sư thế giới

9

Một ngôn ngữ nổi tiếng không có từ khóa là Lisp. Điều gần nhất với các từ khóa được gọi là các hình thức đặc biệt - số lượng của chúng có thể khác nhau giữa các phương ngữ - được đối xử đặc biệt từ người phiên dịch. Ngoài ra, chúng không thể phân biệt được với các hàm thông thường về cách sử dụng chúng, ngoại trừ chúng không thể được định nghĩa lại (ít nhất là trong Lisps tôi quen thuộc).

Điều này dẫn đến một cú pháp đơn giản (nhưng nặng về paren) và là một trong những điều cho phép Lisp có một hệ thống macro mạnh mẽ như vậy. Mặt khác, Lisp thường được cho là khó đọc. APL và MUMPS, thậm chí còn hơn thế, tôi đã thấy cả hai được mô tả là nửa chừng với Brainf * ck. Từ khóa giúp ích trong bộ phận này và làm cho việc đọc mã dễ dàng hơn cho con người chúng ta.

Vì vậy, tôi sẽ không nói từ khóa là cần thiết cho một ngôn ngữ thành công, nhưng chúng chắc chắn sẽ giúp một ngôn ngữ thành công.


1
IIRC Lisp KHÔNG có từ khóa. Các hình thức đặc biệt phải được xử lý đặc biệt bởi trình biên dịch, nhưng tên của chúng là các ký hiệu thông thường.
Jan Hudec

2
Từ khóa là một tính năng của cú pháp, mà Lisp không có. Tôi không nghĩ rằng thậm chí có ý nghĩa khi nói về các từ khóa trong Lisp, thực sự.
Jörg W Mittag

2
Tôi đồng ý với Jörg. Tôi nghĩ rằng người ta có thể nói về các từ khóa khi một ngôn ngữ có mã thông báo phải được xác định rõ ràng là đặc biệt để được phân biệt với các mã thông báo có cấu trúc tương tự. Các mã thông báo khác nhau dẫn đến các cây cú pháp khác nhau. Ví dụ: iftrong C sẽ là một định danh hợp lệ nếu nó không được xác định là đặc biệt (một từ khóa). Điều này có nghĩa là đó ifkhông phải là định danh và if = 10đưa ra lỗi cú pháp. Nếu tôi không nhầm, cú pháp tối thiểu Lisp của không phân biệt defuntừ f, x, y+trong (defun f (x y) (+ x y)).
Giorgio

@Giorgio đáng chú ý if một tên biến hợp lệ trong Common Lisp (và các Lisp-2 khác) (defparameter if nil)sẽ không phá vỡ bất cứ thứ gì và nó có thể được sử dụng trong các hình thức như(unless if (setf if t))
tobyodavies

Trên cùng một lưu ý, mặc dù, (defun if ...)sẽ thất bại. Lấy ghi chú từ các bình luận vào tài khoản và chỉnh sửa câu trả lời. Tôi có thể đồng ý rằng các hình thức đặc biệt không phải là từ khóa ở cùng cấp độ như trong C, ví dụ, chúng vẫn là thứ gần nhất mà Lisp có.
xem xét

8

TCL không có từ khóa và thực sự chỉ có 12 quy tắc cú pháp. mặc dù nó không phổ biến như trước đây, nhưng nó có vị trí thích hợp và được nhúng trong ECAD và bộ định tuyến nên nó chắc chắn được coi là một thực tế đối với tôi.

Tôi cũng nghĩ rằng nó có thể cho thấy tại sao nhiều ngôn ngữ không đi theo con đường này. Có, hoàn toàn có thể viết một trình phân tích cú pháp TCL (dễ dàng hơn nhiều ngôn ngữ khác) tuy nhiên bạn không thể viết một ngữ pháp BNF rất hữu ích cho ngôn ngữ và nhiều người dường như gặp khó khăn khi học ngôn ngữ. Tôi nghi ngờ điều này ít nhất một phần là do thiếu từ khóa.


2
Tcl rất giống với Lisp về vấn đề này, ngoại trừ thay vì "mọi thứ là một danh sách", nó có "mọi thứ là một chuỗi". Một danh sách chỉ là một chuỗi có khoảng trắng trong đó và một lệnh gọi thủ tục chỉ là một danh sách có phần tử đầu tiên được hiểu là tên của một thủ tục và phần còn lại được hiểu là các đối số của nó. Đó thực chất là một biểu hiện Lisp.
Jörg W Mittag

vâng, cả hai đều sử dụng ký hiệu đánh bóng và là biểu tượng đồng tính nên có ngữ nghĩa khá giống nhau
jk.

5

Máy tính đủ mạnh ngày nay để có thể suy ra ý nghĩa từ ngữ cảnh.

Điều này có nghĩa là bạn muốn một ngữ pháp không ngữ cảnh? Chúc may mắn.

Đó không phải là một câu hỏi về việc có mạnh mẽ hay không. Có những quy tắc vĩnh cửu, không thay đổi về ngôn ngữ - toán học. Điều này, và thực tế là một ngôn ngữ lập trình nên dễ dàng về mặt cú pháp sẽ khiến quy tắc CFG trong một vài thập kỷ tới.

Btw., Trong cú pháp như Haskell, bạn chỉ cần viết một cái gì đó như

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

để xác định một chức năng. Nhưng quan sát rằng "từ khóa" trong trường hợp này là '='. Nếu bạn bỏ lỡ nó, những điều khủng khiếp sẽ xảy ra trong trình phân tích cú pháp.

Nhưng đây là một điểm mà tôi đồng ý với bạn, tôi thấy điều này trực quan hơn nhiều so với tất cả các từ khóa def, dcl, fun, fn, function hoặc what-not giới thiệu các chức năng trong các ngôn ngữ khác.

Tuy nhiên, ngữ pháp này có thể được viết bằng LALR cũ (1), không có nghĩa là "suy ra từ ngữ cảnh" ở đây.


1
+1 để giải quyết tuyên bố này (Máy tính đủ mạnh ngày nay để có thể suy ra ý nghĩa từ ngữ cảnh). Tôi nghĩ lý do tại sao các ngữ pháp của CFG được ưa thích là vì chúng cho phép cấu trúc chương trình được xác định theo quy nạp. Tôi không thấy lý do tại sao một người muốn thay đổi điều này ngay cả trong 100 năm nữa, có lẽ tôi chỉ thiếu trí tưởng tượng?
Giorgio

2
CFG khá chết và đã chết trong nhiều thập kỷ. JavaScript bên trong HTML, thậm chí các chuỗi định dạng C bên trong C, thậm chí các bình luận lồng nhau trong, giả sử, OCaml - tất cả nội dung này không phải là ngữ cảnh miễn phí. Và, tại sao bạn muốn hạn chế bản thân theo một hình thức được lựa chọn tùy tiện như vậy, bây giờ, trong thời đại của PEG và GLR?
SK-logic

1
@Ingo, vâng, bạn đúng, một lựa chọn sai của một ví dụ. Tôi có nghĩa là ngữ pháp hỗn hợpmở rộng (nghĩa là thứ tự cao), không phải là CFG.
SK-logic

2
@ SK-logic: Tôi không biết bạn lấy thông tin ở đâu mà CFG đã chết. Tôi đã nói chuyện với một đồng nghiệp cũ của tôi, người đã dạy xây dựng trình biên dịch trong 20 năm qua và CFG dường như còn lâu mới chết.
Giorgio

1
@Ingo: Theo như tôi nhớ, các khía cạnh phi CF được xử lý sau đó bằng cách phân tích cây phân tích ngữ nghĩa. Ví dụ, { int x = 0; x = "HELLO"; }nên tạo một cây phân tích cú pháp nhưng khi trình biên dịch tìm kiếm x trong phép gán thứ hai, nó thấy rằng nó đã được khai báo là int và phát sinh lỗi kiểu. Vì vậy, chương trình bị từ chối ngay cả khi cấu trúc CF của nó là chính xác.
Giorgio

4

Theo như tôi biết, Smalltalk là ngôn ngữ có ít từ khóa nhất (nếu tôi không tính các ngôn ngữ như Brainfuck). Từ khóa Smalltalk là true, false, nil, self, superthisContext.

Tôi đã thiết kế một langage, lấy cảm hứng từ smalltalk, không có từ khóa. Nhưng sau một thời gian sử dụng, cuối cùng tôi đã thêm một vài từ khóa, chủ yếu là đường cú pháp.

Vì vậy, ý kiến ​​của tôi là ngôn ngữ không có từ khóa là có thể, nhưng nó không thực tế lắm và đó là lý do tại sao tất cả các ngôn ngữ phổ biến đều có từ khóa.


Nếu Smalltalk có hỗ trợ cho việc gửi tin nhắn với một người nhận ẩn, thì ít nhất true, falsenilcó thể được định nghĩa là các phương thức trên người nhận ẩn đó, và, với khả năng phản xạ, ba người kia cũng có thể.
Jörg W Mittag

1
Đó không phải là từ khóa, chúng là giả. "Giả" bởi vì true, falsenillà các giá trị nổi tiếng được cung cấp bởi môi trường và self, superthisContextlà các biến bạn không thể đặt nhưng có giá trị thay đổi do kết quả thực hiện.
Frank Shearar

3

Bạn dường như đang lao động theo một giả định sai lầm, rằng các từ khóa ở đó để làm cho mọi thứ dễ dàng hơn cho trình biên dịch. Mặc dù chúng làm cho mọi thứ dễ dàng hơn cho trình biên dịch, nhưng chúng có một lợi ích quan trọng hơn nhiều: chúng làm cho mọi thứ dễ dàng hơn cho người đọc mã .

Vâng, bạn có thể nhìn vào một loạt các bối cảnh và tìm ra rằng bạn đang xem một khai báo hàm hoặc một khai báo biến, nhưng tùy thuộc vào ngữ cảnh và mức độ phức tạp của mã liên quan, có thể mất nhiều thời gian để tìm ra . Hoặc, bạn có thể có một từ khóa tiện dụng ở đó như hàm hoặc var và bạn biết ngay những gì bạn đang xem.

Đúng, họ làm cho mã phức tạp hơn để viết , nhưng xem xét rằng các chương trình tốn nhiều thời gian bảo trì hơn trong sản xuất và mã của họ được đọc, gỡ lỗi và duy trì nhiều hơn so với khi tạo, cố gắng thiết kế ngôn ngữ của bạn làm cho nó dễ viết thay vì dễ đọc là một trường hợp cổ điển của tối ưu hóa sớm có hại.

Ngoài ra, đừng coi thường các khái niệm làm cho công việc của nhà biên dịch dễ dàng hơn. Càng dễ dàng để phân tích, sự nhanh mã của bạn sẽ biên dịch, có nghĩa là chu kỳ chỉnh sửa-build-debug trở nên nhanh hơn, có nghĩa là năng suất của bạn đi lên.

Khi bạn có một cơ sở mã lớn, phức tạp, điều đó có thể dẫn đến sự khác biệt không hề nhỏ trong năng suất. Ví dụ, nơi tôi làm việc, chúng tôi có một chương trình tại nơi làm việc với khoảng 4 triệu dòng Delphi. Chúng tôi có một mô-đun khác khoảng 300.000 dòng C ++. Cả hai đều mất khoảng thời gian như nhau để biên dịch. (Khoảng 3 phút.) Nếu chúng tôi có 4 triệu dòng C ++, có thể mất một giờ để xây dựng!


Tất cả các điểm xuất sắc. +1

nếu mỗi danh từ, động từ, trạng từ và tính từ trong một cuốn tiểu thuyết được dán nhãn như vậy nó sẽ làm cho nó khó đọc hơn!

@JarrodRoberson: Chắc chắn, nó sẽ, nhưng mã không phải là một cuốn tiểu thuyết. Ngôn ngữ tự nhiên rất khác với ngôn ngữ lập trình. Ngôn ngữ tự nhiên được hiểu theo trực giác, trong khi ngôn ngữ lập trình có ngữ nghĩa chính thức. Các kỹ thuật được sử dụng để đọc nó và hiểu ý nghĩa của nó rất khác nhau, và thật sai lầm khi cố gắng đánh đồng hai cái giống như bạn.
Mason Wheeler

Tôi đã nói trình biên dịch trình biên dịch khác với trình biên dịch . Trình biên dịch nhanh hơn trên phần cứng nhanh hơn, người viết trình biên dịch là con người, chúng tôi không tuân thủ Định luật Moore!

các cơ sở mã tôi có xu hướng làm việc với các đơn đặt hàng có độ dài lớn hơn tiểu thuyết, hầu hết là> 1.000.000+ dòng mã, hầu hết các tiểu thuyết dài nhất là <2.000.000 từ ! Và giống như tiểu thuyết chúng được con người đọc, thực sự thời gian dành cho việc đọc mã nhiều hơn là viết nó! Đưa ra một cơ sở mã> 10 năm tuổi và hơn 1.000.000 dòng, số lần nó được đọc bởi các nhà phát triển trong hơn 10 năm lùn thời gian cần thiết để tạo ở vị trí đầu tiên.!

2

Có một số ví dụ hiếm.

APL chỉ sử dụng các biểu tượng - nhưng rất nhiều trong số chúng! Bạn cần một bàn phím đặc biệt để sử dụng ngôn ngữ.

Xem bài viết trên wikipedia này

CORAL 66 - có từ khóa nhưng chỉ nhận ra chúng nếu chúng được trích dẫn bằng dấu ngoặc đơn.

PL / 1 cũng có từ khóa - nhưng bạn cũng có thể sử dụng chúng làm tên biến hoặc thủ tục.

Tất cả trong tất cả mặc dù câu hỏi của bạn hơi giống như hỏi "tại sao ngôn ngữ nói có từ?".


Chỉ cần thêm rằng nếu bạn thích giao diện của APL nhưng không muốn mua bàn phím mới, thì J chính là thứ đó.
AakashM

0

Lý do chính là vì cả người và máy tính đều dễ dàng phân tích cú pháp hơn. Việc định hướng một ngôn ngữ phức tạp không có từ khóa sẽ yêu cầu nhiều ký hiệu làm cú pháp và nó sẽ gây nhầm lẫn lớn và không cần thiết. Nó dễ đọc functionhơn nhiều $!{}. Và bối cảnh không giải quyết được tất cả sự mơ hồ.


1
Tôi nghĩ từ khóa trong câu trả lời của bạn rất phức tạp , một ngôn ngữ được thiết kế đủ nên đơn giản , không phức tạp .

1
@Jarrod Roberson: Leonardo da Vinci: "Đơn giản là sự tinh tế tột cùng", Antoine de Saint Exupéry: "Dường như sự hoàn hảo đạt được không phải khi không còn gì để thêm, nhưng khi không còn gì để lấy đi".
Giorgio

1
@Jarrod: Tất cả các ngôn ngữ máy tính có ý nghĩa biểu cảm đều phức tạp.
DeadMG

1
@DeadMG: Lược đồ rất đơn giản và đồng thời rất biểu cảm. Thật không may, theo như tôi biết nó thiếu một thư viện tiêu chuẩn.
Giorgio

Erlang rất biểu cảm và không phức tạp về mặt cú pháp. Tôi nghĩ rằng tất cả các ngôn ngữ chức năng cuối cùng trở nên biểu cảm hơn với các từ khóa dành riêng ít hơn.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.