Là Lambda Compus hoàn toàn là cú pháp?

Tôi đã đọc vài tuần về Công cụ tính toán Lambda, nhưng tôi chưa thấy bất cứ điều gì khác biệt về mặt vật chất với các hàm toán học hiện có, và tôi muốn biết liệu đó chỉ là vấn đề của ký hiệu, hay liệu có bất kỳ tính năng mới nào không các thuộc tính hoặc quy tắc được tạo bởi các tiên đề tính toán lambda không áp dụng cho mọi hàm toán học. Vì vậy, ví dụ, tôi đã đọc rằng:

"Có thể có chức năng ẩn danh" : Chức năng Lambda không ẩn danh, chúng chỉ được gọi là lambda. Trong ký hiệu toán học được phép sử dụng cùng một biến cho các hàm khác nhau nếu tên không quan trọng. Ví dụ: hai chức năng trong Kết nối Galois thường được gọi là *.

"Các hàm có thể chấp nhận các hàm làm đầu vào" : Không mới, bạn có thể thực hiện điều này với các hàm thông thường.

"Hàm là hộp đen" : Chỉ đầu vào và đầu ra cũng là mô tả hợp lệ của các hàm toán học ...

Điều này có vẻ giống như một câu hỏi thảo luận hoặc ý kiến ​​nhưng tôi tin rằng nên có một câu trả lời "chính xác" cho câu hỏi này. Tôi muốn biết liệu phép tính lambda chỉ là một quy ước hay cú pháp để làm việc với các hàm toán học, hoặc liệu có bất kỳ sự khác biệt đáng kể hoặc ngữ nghĩa nào giữa lambdas và các hàm thông thường.

Trớ trêu thay, tiêu đề là đúng nhưng không phải theo cách bạn có nghĩa là "đó là phép tính lambda chỉ là một quy ước công chứng" không chính xác.

Điều khoản Lambda không phải là chức năng ¹ . Chúng là những phần của cú pháp, tức là bộ sưu tập các ký hiệu trên một trang. Chúng tôi có các quy tắc để thao túng các bộ sưu tập các biểu tượng này, giảm đáng kể beta nhất. Bạn có thể có nhiều khác biệt về lambda rằng tương ứng với các cùng chức năng. ²

Tôi sẽ giải quyết trực tiếp điểm của bạn.

Đầu tiên, lambda không phải là một cái tên đang được sử dụng lại. Điều đó không chỉ vô cùng khó hiểu, mà chúng ta không viết (hoặc ), đó là những gì chúng ta sẽ làm nếu là tên của một hàm, giống như chúng ta viết . Trong chúng ta có thể thay thế (nếu nó được định nghĩa bởi một thuật ngữ lambda) bằng thuật ngữ lambda tạo ra một cái gì đó như có nghĩa là là một biểu thức có thể đại diện cho một hàm, không phải một khai báo khai báo một hàm (có tên$\lambda(x)$$(\lambda\ x)$$\lambda$$f(x)$$f(x)$$f$$(\lambda y.y)(x)$$(\lambda y.y)$$\lambda$hoặc bất cứ điều gì khác). Ở bất cứ giá nào, khi chúng ta quá tải thuật ngữ / ký hiệu, thì (một hy vọng) được thực hiện theo cách mà nó có thể được định hướng qua ngữ cảnh, điều đó chắc chắn không thể xảy ra đối với các thuật ngữ lambda.

Điểm tiếp theo của bạn là tốt nhưng hơi không liên quan. Đây không phải là một cuộc thi trong đó có Điều khoản và Chức năng của Đội Lambda và chỉ có một người có thể giành chiến thắng. Một ứng dụng chính của thuật ngữ lambda là nghiên cứu và hiểu một số loại chức năng. Đa thức không phải là một hàm mặc dù chúng ta thường xuyên xác định chúng một cách cẩu thả. Nghiên cứu đa thức không có nghĩa là người ta nghĩ rằng tất cả các hàm nên là đa thức, cũng không phải là trường hợp đa thức phải "làm" một cái gì đó "mới" để đáng nghiên cứu.

Đặt các hàm lý thuyết không phải là hộp đen, mặc dù chúng được xác định hoàn toàn bởi mối quan hệ đầu vào-đầu ra của chúng. (Chúng thực sự là mối quan hệ đầu vào-đầu ra của chúng.) Các thuật ngữ Lambda cũng không phải là hộp đen và chúng không được xác định bởi mối quan hệ đầu vào-đầu ra của chúng. Như tôi đã đề cập trước đây, bạn có thể có các thuật ngữ lambda riêng biệt tạo ra cùng một mối quan hệ đầu vào-đầu ra. Điều này cũng nhấn mạnh thực tế là các thuật ngữ lambda không thể là hàm, mặc dù chúng có thể tạo ra các hàm. ²

Trên thực tế, sự tương đồng giữa đa thức và thuật ngữ lambda rất gần gũi và tôi nghi ngờ bạn có thể không đánh giá cao sự khác biệt giữa đa thức và hàm mà nó đại diện, vì vậy tôi sẽ giải thích một chút. ³ Thông thường khi đa thức được giới thiệu, thông thường với các hệ số thực, chúng được coi là các hàm thực của một loại cụ thể. Bây giờ hãy xem xét lý thuyết về các thanh ghi dịch chuyển phản hồi tuyến tính (LFSR). Phần lớn là lý thuyết về đa thức (đơn biến) so với , nhưng nếu chúng ta nghĩ đó là hàm , thì có nhiều nhất hàm như vậy. Tuy nhiên, có vô số đa thức trên . ⁴$\mathbb F_2$F 2 → F 2 4 F 2 F 2 → F 2 F 2 2 N → 2 N $\mathbb F_2\to\mathbb F_2$$4$$\mathbb F_2$Một cách để thấy điều này là chúng ta có thể diễn giải các đa thức này như một cái gì đó khác với các hàm , thực sự là bất kỳ hàm nào cũng được. Đối với các LFSR, chúng ta thường hiểu các đa thức là các phép toán trên dòng bit, nếu chúng ta muốn có thể được biểu diễn dưới dạng hàm , mặc dù phần lớn các chức năng như vậy sẽ không có trong hình ảnh của việc giải thích LFSR.$\mathbb F_2\to\mathbb F_2$$\mathbb F_2$$\mathbf{2}^{\mathbb N}\to\mathbf{2}^{\mathbb N}$

Điều này cũng áp dụng cho các thuật ngữ lambda, chúng ta có thể hiểu cả hai điều này là những thứ khác ngoài chức năng. Chúng cũng là những đối tượng dễ điều khiển hơn nhiều so với các hàm chức năng vô hạn điển hình vô tận. Cả hai đều tính toán nhiều hơn các hàm tùy ý. Tôi có thể viết một chương trình để thao tác các đa thức (với các hệ số có thể tính toán được ít nhất là tính toán) và các thuật ngữ lambda. Thật vậy, các thuật ngữ lambda chưa được kiểm tra là một trong những mô hình ban đầu của các hàm tính toán. / Cú pháp mang tính biểu tượng hơn này, calculational / tính toán góc độ thường được nhấn mạnh hơn, đặc biệt đối với untyped calculus lambda, so với cách diễn giải ngữ nghĩa hơn của giải tích lambda. Đánh máyCác thuật ngữ lambda là những thứ dễ quản lý hơn và thường có thể (nhưng không phải luôn luôn) dễ dàng được hiểu là các hàm lý thuyết, nhưng cũng có thể được hiểu thành một lớp thậm chí rộng hơn của các thứ ngoài các hàm so với phép tính lambda chưa được kiểm tra. Họ cũng có một lý thuyết cú pháp phong phú của riêng mình và một mối liên hệ rất sâu sắc với logic .

¹ Có thể vấn đề có thể đi theo một cách khác. Có thể bạn có một sự hiểu lầm về chức năng là gì.

² Điều này thực sự không đơn giản như vậy. Đối với untyped calculus lambda, nó không thực sự có ý nghĩa với ngây thơ giải thích thuật ngữ lambda tùy ý như là chức năng thiết lập lý thuyết . Bạn có thể bắt đầu thấy điều này khi bạn cố gắng nói rõ miền cần diễn giải là gì. Nếu tôi diễn giải một thuật ngữ lambda như là một yếu tố của tập , tôi cũng muốn có thể diễn giải nó như là một hàm trên và thành vì tôi muốn diễn giải ứng dụng là ứng dụng hàm. Bạn kết thúc với (hoặc suy yếu điều này), điều này chỉ đúng với tập đơn. Những gì chúng ta cần cho phép tính lambda chưa được đánh dấu là một đối tượng phản xạ$D$$D$$D$$D^D\subseteq D$và đối với thể loại của tập hợp không có đối tượng phản xạ không tầm thường. Câu chuyện khá khác biệt đối với các thuật ngữ lambda đánh máy , nhưng vẫn có thể không tầm thường.

³ Nếu bạn rõ ràng về sự khác biệt này, thì sự tương tự sẽ khá nhiều thông tin.

⁴ Vấn đề này không xảy ra với các trường có đặc tính 0, như số phức, số thực, số hữu tỷ hoặc số nguyên, do đó, sự phân biệt không sắc nét, mặc dù nó vẫn tồn tại.

Hãy suy nghĩ về khái niệm các biến. Trong các ngôn ngữ cũ như cơ bản, bạn không có phân bổ động và bạn cần một tên cho mỗi biến. (Điều này không hoàn toàn chính xác vì bạn có mảng, nhưng ý tưởng là ...) trong nhiều vấn đề, bạn cần có khả năng phân bổ nhiều biến như bạn muốn, mà không bị giới hạn bởi số lượng tên mà chương trình của bạn xác định.

Các hàm Lambda cho phép bạn thoát khỏi giới hạn tương tự về tên hàm, cho phép chương trình của bạn xác định số lượng hàm cần thiết và "lưu trữ" chúng trong các cấu trúc dữ liệu phức tạp như các biến khác. Đây không phải là điều bạn có thể làm với các hàm được đặt tên thông thường.