Nguồn gốc và ý nghĩa của cụm từ Lamb Lambda là gì?

Tôi đã loay hoay với các ngôn ngữ lập trình chức năng trong một vài năm và tôi tiếp tục gặp cụm từ này. Ví dụ, đó là một chương của "The Little Schemer, chắc chắn có trước blog theo tên này. (Không, chương này không giúp trả lời câu hỏi của tôi.)

Tôi hiểu lambda có nghĩa là gì, ý tưởng về một chức năng ẩn danh vừa đơn giản vừa mạnh mẽ, nhưng tôi không hiểu "cái tối thượng" nghĩa là gì trong bối cảnh này.

Những nơi mà tôi đã thấy cụm từ này:

1. Tiêu đề của chương 8 của The Little Schemer
2. Một blog: http://lambda-the-ultimate.org/
3. Một loạt các bài báo "Lambda the Ultimate X": http : // l Library.readscheme.org/page1.html

Tôi cảm thấy như tôi đang thiếu một tài liệu tham khảo ở đây, bất cứ ai có thể giúp đỡ?

Vâng, nó chỉ đơn giản là một cụm từ lặp đi lặp lại trong tiêu đề của một số bài báo, bắt đầu từ một cặp vợ chồng trong thập niên 70, trong đó Sussman và Steele chứng minh việc sử dụng phép tính lambda để lập trình, bằng phương ngữ Lisp tối giản có tên là " Lược đồ " mà họ nghĩ ra mục đích. Bạn có thể tìm thấy các giấy tờ ở đây ; chúng thú vị và có liên quan đáng ngạc nhiên.

Tôi không chắc liệu điều này có được tuyên bố rõ ràng hay không, nhưng rõ ràng (từ ngữ cảnh, đã đọc các bài báo, và biết nền tảng chung và lợi ích nghiên cứu của các tác giả) rằng cụm từ chỉ đơn giản là một khẩu hiệu hấp dẫn cho sự tranh luận của họ về sự trừu tượng của lambda , với tư cách là một người nguyên thủy tính toán, không chỉ phổ quát theo nghĩa chính thức (có thể mã hóa bất kỳ chương trình nào trong một số thời trang, tuy khó xử), nhưng phổ quát theo nghĩa thực tế là bất kỳ và mọi cấu trúc hiện diện trong các ngôn ngữ khác, ngay cả những ngôn ngữ đó nướng từ dưới lên, có thể được thực hiện lại bằng ngôn ngữ dựa trên lambda theo cách vừa hiệu quả vừa tự nhiên để sử dụng.

Cụm từ lặp đi lặp lại dẫn đến hình thức khái quát rõ ràng "đối với tất cả X, lambda là X cuối cùng", đó là ý nghĩa mà tôi thường lấy "Lambda the Ultimate" có nghĩa là tên blog, lưu ý rằng LtU có liên quan đến ngôn ngữ lập trình thiết kế và lý thuyết. Trớ trêu thay, LtU có lẽ cũng là một trong những nơi tốt nhất để tìm ai đó có thể cho bạn biết về điều gì đó mà lambda không phải là triển khai cuối cùng. :]

Cũng lưu ý rằng Sussman là một trong những tác giả của SICP , một cuốn sách giáo khoa có ảnh hưởng rất lớn cũng sử dụng ngôn ngữ Scheme và dành một lượng thời gian hợp lý để giới thiệu trừu tượng lambda như một khái niệm.

Lambda The Ultimate đề cập đến ý tưởng rằng lambdas của lambda-compus có thể thực hiện hiệu quả mọi khái niệm dựng sẵn trong mọi ngôn ngữ lập trình, quá khứ, hiện tại và tương lai. Các lớp, Mô-đun, Gói, Đối tượng, Phương thức, Dòng điều khiển, Cấu trúc dữ liệu, Macro, Continuations, Coroutines, Generators, List Comp Hiểu, Streams, v.v.

Khi điều đó xảy ra, bản chất tối thượng đó bao gồm việc đứng cho một Hàm ẩn danh. Nhưng lambdas không, ở cốt lõi của chúng, chỉ giới hạn ở các chức năng ẩn danh. Họ được dạy theo cách đó, nhưng bản chất của lambda đi sâu hơn nhiều so với các hàm toán học không có tên. Nói cách khác, tôi có vấn đề với:

Tôi hiểu lambda có nghĩa là gì, ý tưởng về một chức năng ẩn danh vừa đơn giản vừa mạnh mẽ, nhưng tôi không hiểu "cái tối thượng" nghĩa là gì trong bối cảnh này.

Như một vấn đề thực tế, việc sử dụng lambdas như là trừu tượng cú pháp ('macro'), không phải là gọi theo giá trị / ứng dụng (mà các chức năng toán học), là rất quan trọng để mua vào ý tưởng rằng lambdas thực sự có thể phục vụ như là cốt lõi của mọi hệ thống xử lý ngôn ngữ lập trình.

Đối với lý thuyết: Có một mối liên hệ thú vị với nghịch lý của Bertrand Russell và Tiên đề của sự hiểu biết (và mở rộng) trong lý thuyết tập ngây thơ. Lambda là để thực hiện chức năng mà ký hiệu của trình xây dựng là đối với các tập hợp: lambdas là ký hiệu của trình xây dựng hàm. Có một sự khác biệt quan trọng, thường bị bỏ qua, giữa (lambda (x) (* xx)) và những gì đánh giá (hàm bình phương). Nếu người ta không phân biệt được giữa hai loại nói chung, nghĩa là, giữa ký hiệu và ký hiệu (một lỗi mà cả Church và Frege đều mắc phải) thì người ta sẽ gặp phải những nghịch lý. Đối với các bộ và Frege, đó là Thợ cắt tóc Seville của Bertrand Russell minh họa lỗi; đối với các chức năng và Giáo hội, đó là Dừng hoạt động của Alan Turing.

Lưu ý rằng những nghịch lý là tốt, thực tế, mọi thứ. Chúng tôi muốn EVAL có thể biểu lộ được và chúng tôi muốn lambdas có ý nghĩa nhiều hơn là các chức năng. Giả sử ngược lại dẫn đến mâu thuẫn là kết quả mong muốn; nó phục vụ như một bài kiểm tra vệ sinh tốt đẹp: lambdas khó có thể là tối thượng nếu chúng chỉ thể hiện các chức năng đơn thuần.

Vợt (trước đây là PLT Scheme) tiếp tục truy tố ý tưởng rằng các ngôn ngữ lập trình thực tế thực sự có thể được xây dựng, từ đầu, trên 'chỉ lambda'.

Kernel , bởi Shutt, lập luận rằng lambda không thực sự là sự trừu tượng hóa cuối cùng. Ông lập luận rằng có một khái niệm còn nguyên thủy hơn (đối với tiếng Hy Lạp, được đặt tên là vau) được Sussman gọi là FEXPR.

Felleisin và công ty (đối với Vợt) nhận được nhiều sức mạnh của Shutt vau bằng cách sử dụng khái niệm pha , hoặc kim loại, nghĩa là chạy mã nguồn qua nhiều giai đoạn dịch (như với tiền xử lý C, nhưng sử dụng cùng một ngôn ngữ ở mỗi giai đoạn 'Bước' và 'bước' không thực sự hoàn toàn khác biệt về thời gian). (Vì vậy, họ cho rằng một lambda trong một giai đoạn cao hơn xấp xỉ một vầu cũng đủ). Trong thực tế, họ cho rằng giai đoạn là tốt hơn so với FEXPRs, chính xác vì nhiều hạn chế; Nói tóm lại, "FEXPRs quá mạnh" (xem tác phẩm của Wand, mà Shutt lập luận chống lại).

3-Lisp của Brian Smith, "Sự phản ánh thủ tục trong các ngôn ngữ lập trình", cố gắng cải cách nghiêm ngặt lý thuyết về các ngôn ngữ giống như LISP dọc theo các ký hiệu phân biệt rõ ràng (ký hiệu / ngôn ngữ / chương trình) từ các ký hiệu (sự vật / giới thiệu / giá trị / kết quả ). http://dspace.mit.edu/handle/1721.1/15961

"Lý thuyết về FEXPRs là tầm thường" của Mitchell Wand gửi thêm đinh vào quan tài (tạm thời?) Mà Kent Pittman đã rèn cho FEXPR (người, giống như Felleisen, lập luận chống lại FEXPRs vì quá trình biên dịch quá khó).

Paul Graham lập luận với sức mạnh và độ dài trong "On Lisp" rằng sức mạnh thực sự là lambdas như là biến thế của cú pháp (macro), chứ không phải là biến đổi của các giá trị (hàm toán học). Sự phát triển của Plotkin về tính toán lambda ứng dụng có thể được coi là hơi tương phản, bởi vì Plotkin giới hạn tính toán của Church đối với tập hợp con theo giá trị / ứng dụng của nó. Tất nhiên, xử lý phần áp dụng một cách hiệu quả là rất quan trọng, vì vậy điều quan trọng là phát triển lý thuyết chuyên ngành cho việc sử dụng lambda. (Plotkin và Graham không tranh cãi với nhau.)

Trên thực tế, nói chung, khái niệm Lambda là Ultimate chỉ là một bước ngoặt như vậy đối với cuộc tranh luận muôn thuở giữa hiệu quả và tính biểu cảm; đó là vị trí mà lambda là công cụ tối ưu cho tính biểu cảm, và, nếu được nghiên cứu đủ, cuối cùng sẽ chứng minh là công cụ tối ưu cho hiệu quả. Nói cách khác, chúng ta có thể, nếu chúng ta muốn, nhìn thấy tương lai của các ngôn ngữ lập trình là không có gì khác hơn là nghiên cứu về cách thực hiện hiệu quả tất cả các đoạn có liên quan thực tế của phép tính lambda.

"700 ngôn ngữ lập trình tiếp theo" của Landin, http://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf , là một tài liệu tham khảo có thể truy cập góp phần vào sự phát triển của khái niệm đó rằng Lambda là Ultimate.

Tôi đoán nó chỉ đơn giản là một tài liệu tham khảo cho một số bài báo được viết bởi Sussman và Steele trong khoảng thời gian từ 1975 đến 1980 được gọi là:

• Lambda: mệnh lệnh tối thượng
• Lambda: Tuyên ngôn cuối cùng
• Lambda: GOTO tối thượng
• LAMBDA: Opcode cuối cùng

Xem bài viết Wikipedia.