Khả năng đọc biểu thức S


9

Tóm lại và đối với những người không biết về nó, các hàm / toán tử / cấu trúc Lisp đều được gọi một cách thống nhất như thế này:

(function arg0 arg1 ... argN)

Vì vậy, những gì trong một ngôn ngữ giống như C, bạn sẽ thể hiện như là

if (a > b && foo(param))

được chuyển đổi thành một Lisp sexp như

(if (and (> a b) (foo param)))

. Khi mọi thứ trở nên thực tế / phức tạp hơn, thì đối với biểu thức s tương ứng của chúng cũng vậy.

Tôi biết rằng đây rất có thể là một câu hỏi chủ quan, nhưng - đối với nhiều tin tặc Lisp, điều này có một chút phiền toái mà người ta sẽ luôn phải đối phó?

Hay một người hầu hết đã quen với cú pháp (thiếu) này sớm hay muộn?

Trong mọi trường hợp, việc thêm các điểm dừng (mà bạn sẽ không thêm vào tương đương C, hầu hết các lần) để dễ đọc là một ý tưởng hay, đặc biệt là về lâu dài? Bất kỳ đề nghị khác sẽ được hoan nghênh.


1
Bạn đã thử sử dụng Lisp trong môi trường nhận biết Lisp như emacs chưa? Tôi sẽ không chạm vào nó theo bất kỳ cách nào khác.
David Thornley

Không, tôi không biết, hình thức nào có thể cải thiện trải nghiệm Lisp của tôi?
vemv

viết các hàm ngắn cũng rất quan trọng, mặc dù tôi chỉ thực hiện một số cách chơi với clojure.
Kevin

3
Trong một môi trường Lisp tốt, bạn bỏ qua dấu ngoặc đơn và đọc cấu trúc bằng cách thụt lề. Như bạn đã nhận thấy, đọc cấu trúc bằng cách đếm dấu ngoặc đơn thực sự rất khó chịu.
David Thornley

Câu trả lời:


8

Làm thế nào để bạn phân tích

if (a > b && foo(param)) {
  doSomething();
} else {
  doSomethingElse();
}

Cây phân tích có thể trông giống như

if:
  condition:
    and:
      lt:
        left: a
        right: b
      function:
        name: foo
        param: param
  true-block:
    function:
      name: doSomething
  false-block:
    function:
      name: doSomethingElse

hmm ... hãy tuần tự hóa cây này thành một danh sách, ký hiệu tiền tố

if(and(<(a, b), function(foo, param)), function(doSomething), function(doSomethingElse))

Định dạng cây phân tích cú pháp này khá dễ thao tác, nhưng tôi có một vấn đề. Tôi ghét dải phân cách. Tôi thích những kẻ hủy diệt. Đồng thời, tôi thích rắc vào khoảng trắng.

if( and (<(a b) function(foo param)) function (doSomething) function ( doSomethingElse))

hmm ... khoảng trắng bổ sung làm cho một số thứ khó phân tích hơn ... Có lẽ tôi chỉ có thể đưa ra một quy tắc rằng cây được biểu thị là (lá lá rễ).

(if (and (< a b) (function foo param)) (function doSomething) (function doSomethineElse)

Bây giờ việc tuần tự hóa một cây phân tích của tôi là không thể (đổi tên hàm để áp dụng, và điều này có thể chạy). Nếu tôi muốn các chương trình viết chương trình, thật tuyệt khi chỉ thao tác với các cây phân tích cú pháp.

Đây không hoàn toàn là cách biểu thức s xuất hiện, nhưng nó đã được xác định sớm và đó là một tính năng mà các lập trình viên không thể sử dụng. Các chương trình của chúng tôi được phân tích trước theo một số nghĩa và việc viết chương trình để thao tác các chương trình khá dễ dàng vì định dạng. Đó là lý do tại sao việc thiếu cú ​​pháp đôi khi được coi là một thế mạnh.

Nhưng như David nói, hãy sử dụng một trình soạn thảo nhận biết biểu thức s. Bạn có nhiều khả năng mất dấu vết của dấu ngoặc nhọn trong biểu thức s hơn là dấu ngoặc đóng trong xml ( </foo>chỉ đóng <foo>, nhưng paren phải đóng biểu thức BẤT K)). Trong vợt, việc sử dụng dấu ngoặc vuông cho một số biểu thức, kết hợp với kiểu thụt lề tốt, khắc phục hầu hết các vấn đề.

Phiên bản lisp:

(if (and (< a b) (foo param))
  (doSomething)
  (doSomethingElse))

Không tệ lắm.


Danh sách linh hoạt và mạnh mẽ hơn exprs + tuyên bố không có nghi ngờ. Dùng thử Emacs (hoặc những gì khác?) Rất hấp dẫn nhưng lần gần đây nhất tôi đã thử nó chỉ làm tôi sợ rất nhiều. Nhận thức sexp mang lại chính xác những gì?
vemv

Nội dung đơn giản: chúng tạo ra một điểm nổi bật trên các parens đóng và mở (hoặc làm nổi bật toàn bộ biểu thức s khác nhau). Họ có quy tắc thụt lề tốt đẹp. Emacs có những thứ khác, nhưng có lẽ chúng không quan trọng đối với khả năng đọc. Có các biên tập viên nhận thức s-biểu hiện khác. Bạn không cần emacs. Nếu emacs làm bạn sợ, hãy thử các gói cho textmate, cao siêu, v.v. Một khi trình soạn thảo của bạn bắt đầu giúp đỡ với khả năng đọc, mọi thứ trở nên dễ dàng hơn một chút. Tôi làm hầu hết các công cụ lispy trong vợt, cho phép dấu ngoặc vuông ở bất cứ nơi nào có thể sử dụng parens. Có thể chuyển lên giúp dễ đọc.
ccoakley

1
Như một bên, sử dụng cho phép lồng nhau, định nghĩa, vv phá vỡ những thứ đó thành những phần nhỏ hơn. Nếu bạn không thể đưa ra một cái tên hay cho một đoạn, hãy coi đó là một cảnh báo về thiết kế của bạn. Tìm sự cân bằng giữa quá nhỏ để đặt tên và quá lớn để đọc.
ccoakley

Ôi lời khuyên cuối cùng là ... đáng nhớ :) Đang thử Sublime khi tôi đang viết bài này.
vemv

5

Điều thực sự thú vị về s-exp là sau một thời gian ngắn, bạn không nhìn thấy chúng nữa, nó giống như con trăn trong mắt bạn NHƯNG máy tính vẫn có cây dễ dàng.

  • Vì vậy, thụt lề là tự động, không có sự mơ hồ, bạn không phải nhấn tab hai lần hoặc một cái gì đó tương tự khi bạn muốn kết thúc một khối.

  • Nếu bạn chọn một số mã ngẫu nhiên, toàn bộ nội dung có thể dễ dàng thụt lề chỉ bằng một lệnh từ trình chỉnh sửa yêu thích của bạn

  • Bạn có thể điều hướng qua mã của mình thực sự dễ dàng, chuyển giữa s-exp, trao đổi chúng và v.v. với một trình soạn thảo tốt

Thêm vào đó, vì dữ liệu bạn đang thao tác giống với mã bạn đang viết, bạn có thể sử dụng cùng một ngôn ngữ để thao tác mã của mình phải không?

Chà, bạn có thể làm điều đó, đó là macro, bạn thao tác mã bạn đang viết trước khi nó được đánh giá giống như bất kỳ danh sách nào khác, đó là lý do tại sao người ta nói rằng Lisp là "Ngôn ngữ lập trình lập trình". Bạn viết mã viết mã cho bạn.

Đây là một bài viết hay mô tả bản chất của Lisp và tại sao các lập trình viên Lisp cười toe toét khi họ nhìn thấy XML.

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.