Các chi tiết thực hiện của các ngôn ngữ khai báo vốn có bắt buộc

Question

Tôi đang đọc 'Lập trình chức năng' bởi Tomas Petricek & Jon Skeet và tôi hiểu sự khác biệt giữa việc lập trình mệnh đề & bắt buộc.

Điều tôi đang tự hỏi là các toán tử nguyên thủy được thực hiện như thế nào, các ngôn ngữ khai báo được xây dựng từ các toán tử bắt buộc &.

Cheers

AWC

Answer 1

Nếu tôi hiểu câu hỏi của bạn một cách chính xác, tôi không nghĩ rằng đó là một quy tắc cứng và nhanh chóng. Ví dụ, bạn có thể sử dụng một ngôn ngữ chức năng như Lisp, để tạo một trình thông dịch cho chính nó. Trong trường hợp này, các chi tiết thực hiện được thực hiện một cách chức năng (vì Lisp là một ngôn ngữ chức năng).

Ngoài ra, nếu bạn có ngôn ngữ Turing Complete, bạn có thể sử dụng ngôn ngữ đó để triển khai trình phân tích cú pháp/phiên dịch/trình biên dịch cho bất kỳ ngôn ngữ nào khác. Có các ngôn ngữ Turing-Complete bắt buộc và các ngôn ngữ Turing-Complete đầy đủ chức năng/khai báo.

Nhưng tất cả mã cuối cùng đều được thực hiện để lắp ráp hoặc mã máy, vốn vốn bắt buộc. Về lý thuyết, những gì tôi đã nói ở trên là đúng, nhưng rõ ràng là không thực hành :).

Là một lịch sử thú vị sang một bên, LISP là một cấu trúc lý thuyết hoàn toàn; nó là một ký hiệu toán học cho các ngôn ngữ máy tính. Nó vẫn lý thuyết cho đến khi chức năng eval của LISP được thực hiện trong mã máy của Steve Russel trên một máy IBM 704:

Theo những gì được báo cáo của Paul Graham trong Hackers & Họa sĩ, tr. 185, McCarthy nói: "Steve Russell đã nói, nhìn xem, tại sao tôi không lập chương trình eval này ..., và tôi nói với anh ta, ho, ho, bạn đang bối rối lý thuyết với thực hành, điều này eval là dành cho đọc, không phải cho máy tính.Nhưng ông đã đi trước và đã làm nó.Đó là, ông biên dịch eval trong giấy của tôi vào mã máy IBM 704, sửa lỗi, và sau đó quảng cáo này như là một thông dịch viên Lisp, mà nó chắc chắn là. điểm đó Lisp về cơ bản là hình thức mà nó có ngày hôm nay ... " (nhấn mạnh mỏ)

Vì vậy, một lần nữa, sự tinh tế giữa lý thuyết và thực hành. :)

Answer 2

Máy cấp thấp (CPU, cấp độ ngôn ngữ lắp ráp) là bắt buộc vì vậy rõ ràng tại một số điểm việc triển khai sẽ phải tính đến điều đó. Tuy nhiên, Implementing certain kinds of functional languages like Haskell có một số cách tiếp cận rất không rõ ràng để tạo ra một thời gian chạy với hiệu suất tốt.

Thật kỳ lạ, ngôn ngữ bắt buộc hầu hết đi qua một giai đoạn mà tất cả các mã được chuyển thành thể khai báo nhiều hơn:

• Single Static Assignment

Dưới đây là một ví dụ về soạn thảo Đề án (chức năng) trực tiếp đến Mã C (bắt buộc):

• The 90 minute Scheme to C compiler

Answer 3

Câu hỏi của bạn có một chút không rõ ràng. Dưới mui xe, hướng dẫn xử lý là bắt buộc trong tự nhiên. Nếu mã của bạn được cho là chạy trên một máy von Neumann, nó cuối cùng sẽ được chạy như mã lệnh bắt buộc.

Có thể xây dựng một máy (với một số kiến ​​trúc cụ thể) vốn đã hỗ trợ các hoạt động đó. Trong thực tế, LispM đã được thiết kế để giúp chạy các chương trình Lisp. Trong khi tôi không quen thuộc với các đặc tính phần cứng của LispM, nó có thể không đủ điều kiện như cung cấp một số hoạt động nguyên thủy ở mức khai báo cao hơn.

Answer 4

Ngôn ngữ khai báo được xây dựng từ các toán tử bắt buộc & có hoạt động không?

Đôi khi. Đây là thuộc tính của việc triển khai , không phải là ngôn ngữ .

Trong thập niên 1980, nhiều người đã biên dịch các chương trình chức năng thành đồ thị, sau đó viết lại biểu đồ cho các biểu đồ đơn giản hơn. Tính toán này thường liên quan đến việc cập nhật các đồ thị tại chỗ, nhưng nếu không nó được về như một khai báo như bạn muốn. Để tìm hiểu thêm, hãy tìm "giảm đồ thị" hoặc đọc "Động cơ giảm bốn kỳ" của Chris Clack và Simon Peyton Jones.

Cuối cùng, các nhà văn trình biên dịch đã tìm ra cách để có được hiệu suất tốt hơn bằng cách biên dịch các chương trình chức năng trực tiếp thành mã máy gốc. Nếu máy bản địa là một máy hàng hóa điển hình, điều này có nghĩa là các hoạt động bắt buộc điển hình. Tuy nhiên, nếu bạn tìm kiếm công trình tiên phong của Giáo sư Arvind tại MIT, nhóm của ông đã thiết kế và xây dựng các máy dữ liệu dataflow nơi các hoạt động tính toán cơ bản mang tính khai báo nhiều hơn. Đó là một công trình tuyệt vời, nhưng tất cả các kiến ​​trúc chuyên dụng phát triển mạnh mẽ trong thập niên 1980 đã bị tuyệt chủng bởi chu kỳ đạo đức tuyệt vời của Microsoft (nhiều phần mềm hơn -> nhiều máy tính hơn được bán -> bộ xử lý rẻ hơn -> nhiều máy tính được bán -> .. -> $ 300 netbook thực sự làm những thứ tuyệt vời.

Answer 5

triển khai là 'ẩn dưới mui xe. nó có thể được xây dựng với bất kỳ mô hình nào.

chương trình khai báo chỉ là một dữ liệu cho việc triển khai thực hiện mệnh lệnh "phổ quát" nhiều hơn hoặc ít hơn của nó/vm.

Điểm cộng: chỉ định dữ liệu, ở một số định dạng được mã hóa (và được kiểm tra), đơn giản hơn và ít bị lỗi hơn chỉ định trực tiếp một số thuật toán bắt buộc. một số chi tiết kỹ thuật phức tạp không thể được viết trực tiếp, chỉ trong một số hình thức DSL. tốt nhất và freq được sử dụng trong cấu trúc dữ liệu DSL là bộ và bảng. bởi vì bạn không có sự phụ thuộc giữa các phần tử/hàng. và khi bạn thuê phụ thuộc, bạn có quyền tự do sửa đổi và dễ dàng hỗ trợ.(so sánh các mô-đun với các lớp - với các mô-đun bạn hài lòng và với các lớp bạn có vấn đề lớp cơ bản mong manh) tất cả các hàng hóa của tính đột biến và DSL theo ngay lập tức từ lợi ích của cấu trúc dữ liệu đó (bảng và bộ). một điểm cộng khác - bạn có thể thay đổi việc triển khai ngôn ngữ khai báo vm, nếu DSL là trừu tượng nhiều hơn hoặc ít hơn (được thiết kế tốt). thực hiện song song, ví dụ. hoặc chuyển nó sang hệ điều hành khác, v.v. tất cả các giao diện hoặc giao thức cô lập mô-đun đặc biệt tốt sẽ mang lại cho bạn sự tự do và sự hỗ trợ dễ dàng như vậy.

minuses: bạn đoán đúng. generic (và tham số hóa bởi DSL) thuật toán bắt buộc/thực thi vm có thể chậm hơn và/hoặc bộ nhớ đói hơn so với một cụ thể. trong vài trường hợp. nếu trường hợp đó hiếm - chỉ cần quên nó đi, hãy để nó bị chậm. nếu nó thường xuyên - bạn luôn có thể mở rộng DSL/vm của bạn cho trường hợp đó. một nơi nào đó làm chậm tất cả các trường hợp khác, chắc chắn ...

P.S. Khung là một nửa giữa DSL và bắt buộc. và như tất cả các giải pháp nửa chừng ... chúng kết hợp các khiếm khuyết, không phải lợi ích. họ không an toàn và không quá nhanh :) nhìn vào jack-of-all-trades haskell - đó là nửa đường giữa ML đơn giản mạnh mẽ và linh hoạt metaprog Prolog và ... thật là quái vật. bạn có thể xem Prolog như một Haskell với các hàm/các biến vị ngữ chỉ có boolean. và sự linh hoạt của nó đơn giản như thế nào đối với Haskell ...