Là sự tương đương theo ngữ cảnh của một ngôn ngữ với `quote`-`eval` tầm thường hay không?


13

Trong [1], Mitchell Wand đã chứng minh rằng việc thêm fexprs vào phép tính lambda thuần túy làm tầm thường hóa lý thuyết tương đương theo ngữ cảnh, nghĩa là hai thuật ngữ tương đương với ngữ cảnh nếu chúng là -congruent. Khi khám phá các công việc liên quan, ông đã đi "kết quả của chúng tôi mở rộng một quan sát cũ về Albert Meyer [2] và đưa ra tầm thường tương đương theo ngữ cảnh". Nhưng đề cập đến [2], những gì có thể tìm thấy chỉ là tuyên bố sau của Meyer:αevalquote

Tôi nghĩ rằng trong các ngôn ngữ có một quote- evaltính năng như LISP [3] không có sự phân biệt kiểu giữa các đối tượng cú pháp và thực thi. Trên thực tế quote- evalcó vẻ đủ an toàn trong LISP bởi vì, mặc dù quotevề mặt cú pháp trông giống như một nhà điều hành trung thực, như nói cond, nó thực sự không hoạt động như một (nó chỉ có hành vi tại thời điểm phân tích, không chạy thời gian, ví dụ, người ta không thể vượt qua quotenhư là một tham số cho một thủ tục). Tuy nhiên, tôi vẫn chưa thấy các ví dụ thuyết phục trong đó tính năng quote- evalđáng giá.

Bất kể một lỗ hổng nhỏ nào trong những bình luận này có thể khiến người đọc hiểu lầm rằng condcó thể được chuyển qua như một tham số cho một thủ tục. Nếu tôi hiểu chính xác, những gì Meyer nói " quote- evalcó vẻ đủ an toàn" có nghĩa là quote- evalcó thể không tầm thường hóa lý thuyết công bằng, mặc dù ông không đưa ra một bằng chứng.

BIÊN TẬP:

Theo đề xuất của Martin, vì cả ba bài báo được trích dẫn liên quan đến ngôn ngữ gia đình LISP, chúng ta hãy đặt câu hỏi dưới cùng một cài đặt này. Là sự tương đương theo ngữ cảnh của một ngôn ngữ với quote- eval, đặc biệt là LISP, trên trái đất có tầm thường hay không?

[1] Mitchell Wand, Lý thuyết về Fexprs là tầm thường . Lisp và tính toán tượng trưng 10 (3): 189-199 (1998).

[2] Albert Meyer, Câu đố trong Hội thảo Logic lập trình về phát triển phần mềm chính thức. 1984

[3] John McCarthy, hàm đệ quy của biểu thức tượng trưng và tính toán của họ bằng máy, Phần I . Truyền thông của ACM vào tháng 4 năm 1960.


1
Tôi sẽ đề nghị xem xét nếu bạn có thể làm cho câu hỏi cụ thể hơn: có nhiều cách khác nhau để thực hiện eval / quote như các cấu trúc và các tùy chọn khác nhau trong việc thiết kế các tương đương theo ngữ cảnh cho các phép tính như vậy. Một ấn phẩm thú vị gần đây là Lý do về các chương trình nhiều giai đoạn của Inoue, Taha.
Martin Berger

1
Sự khác biệt chính là giữa CTMP (lập trình meta thời gian biên dịch, như được minh họa bởi Template Haskell, Lisp / Scheme / Rairs và Converge và RTMP (lập trình meta thời gian chạy như eval của Javascript hoặc MetaOCaml). . Dưới đây là một talk tổng quan tôi đã đưa ra một vài tháng trở lại về vấn đề này, khá nông cạn tôi sợ về tương đồng ngữ cảnh, ít công việc đã được thực hiện, chủ yếu là sở hữu sang trạng thái lỏng của chương trình hỗ trợ cho các meta-lập trình..
Martin Berger

1
@ plmday: BTW, ngôn ngữ lập trình lý tưởng hóa Wand chính thức trong Lý thuyết về Fexprs Is Trivial khá khác biệt so với Lisp lập trình meta. Cái trước là RTMP, cái sau (tùy theo triển khai cụ thể) thì không.
Martin Berger

1
@MartinBerger: Bạn có thể đăng bài nói chuyện của bạn dưới dạng pdf không?
Dave Clarke

1
@ Dave Clarke, chắc chắn rồi, đây rồi! Phản hồi chào mừng.
Martin Berger

Câu trả lời:


2

Đầu tiên, điều này hoàn toàn phụ thuộc vào những gì bạn coi là bối cảnh của bạn. Nếu (quote [])là một bối cảnh, thì tương đương ngữ cảnh là tương đương cú pháp.

Theo truyền thống, các bối cảnh cho sự tương đương theo ngữ cảnh được coi là bối cảnh trong đó "biểu thức", theo bất kỳ ý nghĩa nào có trong ngôn ngữ, có thể xuất hiện. Điều này loại trừ các bối cảnh như "[]", trong đó bối cảnh đặt đối số của nó bên trong một chuỗi ký tự. Những loại bối cảnh này cũng được, IIRC, loại trừ bởi Quine khi ban đầu ông mô tả tính minh bạch tham chiếu.

Từ quan điểm này, tôi nghĩ (quote [])cũng không phải là một bối cảnh. Thay vào đó, bối cảnh là nơi đánh giá biểu thức có thể xảy ra, chẳng hạn như trong phần thân của hàm hoặc trong đối số của ứng dụng.

Có khả năng có vấn đề, điều này có nghĩa là trong chương trình Lisp có macro (hoặc chương trình Vợt hoặc Lược đồ), bạn không biết bối cảnh là gì cho đến khi bạn chạy quy trình mở rộng macro có khả năng sắp hết, bởi vì bạn thậm chí không biết biểu thức ở đâu Chúng tôi. Cho dù bạn nghĩ rằng đây là một vấn đề hay không chủ yếu là một câu hỏi triết học hơn là một câu hỏi kỹ thuật.


Tôi nghĩ có một cách để loại trừ (quote []), thay vì mơ tưởng, như một bối cảnh: gạt bỏ ý tưởng coi 'datumđường cú pháp cho (quote datum), sau đó '[], "[]"không còn là bối cảnh nữa. Các lược đồ macro vẫn bị che khuất quote.
ngày

Tôi không hiểu bình luận của bạn, @day. Tại sao mối quan hệ giữa 'datum(quote datum)thay đổi bất cứ điều gì?
Sam Tobin-Hochstadt

Nếu quotelà một ngôn ngữ xây dựng và 'datumdesugars (quote datum), mọi người sẽ có nhiều khả năng tranh luận đó (quote [])là một bối cảnh. Nếu chúng ta loại bỏ quotekhỏi ngôn ngữ cốt lõi, nhưng hỗ trợ 'datumcú pháp theo nghĩa đen , thì chúng sẽ ít có khả năng tranh luận như vậy bởi vì sự tương tự "[]"được biết đến không phải là một bối cảnh.
ngày

@day, đây là một sự hiểu lầm. Không có định nghĩa đúng về "bối cảnh". Chỉ là các bối cảnh khác nhau hỗ trợ các quan niệm khác nhau về sự tương đương theo ngữ cảnh. Ví dụ, khoảng trắng có ý nghĩa về mặt ngữ nghĩa trong "[]"ngữ cảnh, nhưng không phải trong (quote [])ngữ cảnh. Những gì "người" có thể tranh luận là không ở đây và cũng không có.
Sam Tobin-Hochstadt

Tôi đồng ý rằng không có một định nghĩa đúng về bối cảnh. Nhưng có một định nghĩa truyền thống dựa trên cú pháp trừu tượng, cái mà Wand sử dụng trong bài báo của mình và Meyer sử dụng trong bài viết của mình, để đặt câu hỏi về tình trạng tương đương theo ngữ cảnh của Lisp. Những gì bạn đề xuất là thay thế định nghĩa truyền thống của bối cảnh bằng bối cảnh đánh giá. Những gì tôi đề xuất là giữ định nghĩa truyền thống về bối cảnh, loại bỏ quotekhỏi cú pháp trừu tượng, nhưng hỗ trợ cú pháp bằng chữ (cụ thể) của trích dẫn (không đáng kể). Từ những gì tôi có thể thấy, cả hai cách đều dẫn đến "Không" cho câu hỏi ban đầu.
ngày
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.