JavaScript có được giải thích theo thiết kế không?

Tôi thận trọng khi đặt câu hỏi này vì nó có vẻ quá khó tính. Tôi vừa mở JavaScript: Hướng dẫn dứt khoát và nó nêu lên trang đầu tiên của chương 1

"JavaScript là ngôn ngữ lập trình được giải thích ở mức độ cao, năng động, chưa được kiểm tra

Vì vậy, tôi có thể cho rằng phần được diễn giải là một yêu cầu trong đặc tả ngôn ngữ, hay là sai lầm khi nói rằng ngôn ngữ là ngôn ngữ lập trình được giải thích khi tôn trọng sự khác biệt giữa một ngôn ngữ và nhiều cách triển khai của nó?

Rõ ràng không có trình biên dịch tĩnh cho JavaScript - https://stackoverflow.com/questions/1118138/is-there-a-native-machine-code-compiler-for-javascript vì vậy có lẽ đó chỉ là sự phản ánh của điều này.

Vì vậy, tôi có thể cho rằng phần được diễn giải là một yêu cầu trong đặc tả ngôn ngữ, hay là sai lầm khi nói rằng ngôn ngữ là ngôn ngữ lập trình được giải thích khi tôn trọng sự khác biệt giữa một ngôn ngữ và nhiều cách triển khai của nó?

Các chuyên viên máy tính ngôn ngữ EcmaScript thường sử dụng thuật ngữ "Trình thông dịch ES" để chỉ việc triển khai EcmaScript, nhưng thông số kỹ thuật không sử dụng thuật ngữ đó. Các tổng quan về ngôn ngữ đặc biệt mô tả các ngôn ngữ về thông dịch-agnostic:

ECMAScript dựa trên đối tượng: ngôn ngữ cơ bản và phương tiện lưu trữ được cung cấp bởi các đối tượng và chương trình ECMAScript là một cụm các đối tượng giao tiếp.

Vì vậy, EcmaScript giả định một "môi trường máy chủ" được định nghĩa là nhà cung cấp các định nghĩa đối tượng bao gồm tất cả các liên kết cho phép I / O hoặc bất kỳ liên kết nào khác với thế giới bên ngoài, nhưng không yêu cầu trình thông dịch.

Các ngữ nghĩa của các câu lệnh và biểu thức trong ngôn ngữ được định nghĩa theo các đặc điểm kỹ thuật hoàn thành được thực hiện một cách tầm thường trong một trình thông dịch, nhưng đặc tả không yêu cầu điều đó.

8,9 Loại đặc tả hoàn thành

Các loại Hoàn thành được sử dụng để giải thích hành vi của báo cáo ( break, continue, returnvà throw) mà thực hiện chuyển không cục bộ tầm kiểm soát. Các giá trị của loại Hoàn thành là bộ ba của biểu mẫu ( loại , giá trị , mục tiêu ), trong đó loại là một trong các giá trị bình thường , phá vỡ , tiếp tục , trả lại hoặc ném , giá trị là bất kỳ giá trị ngôn ngữ ECMAScript hoặc trống và mục tiêu là bất kỳ định danh ECMAScript nào hoặc rỗng .

Thuật ngữ hoàn thành đột ngột, đề cập đến bất kỳ sự hoàn thành nào với một loại khác hơn bình thường .

Việc chuyển điều khiển không cục bộ có thể được chuyển đổi thành các mảng hướng dẫn với các bước nhảy cho phép biên dịch mã gốc hoặc mã byte.

"Công cụ EcmaScript" có thể là một cách tốt hơn để diễn đạt cùng một ý tưởng.

Không có trình biên dịch tĩnh cho JavaScript rõ ràng

Đây không phải là sự thật. "Trình thông dịch" V8 biên dịch thành mã gốc bên trong, Rhino tùy ý biên dịch sang mã byte Java bên trong và nhiều trình thông dịch Mozilla khác nhau ({Trace, Spider, Jager} Monkey) sử dụng trình biên dịch JIT.

V8 :

V8 tăng hiệu suất bằng cách biên dịch JavaScript thành mã máy gốc trước khi thực thi nó, so với thực thi mã byte hoặc giải thích nó.

Tê giác :

public final void setOptimizationLevel(int optimizationLevel)

Đặt mức tối ưu hóa hiện tại. Mức tối ưu hóa được dự kiến ​​là một số nguyên nằm trong khoảng -1 đến 9. Mọi giá trị âm sẽ được hiểu là -1 và mọi giá trị lớn hơn 9 sẽ được hiểu là 9. Mức tối ưu hóa -1 cho biết chế độ diễn giải sẽ luôn luôn là đã sử dụng. Cấp độ 0 đến 9 chỉ ra rằng các tệp lớp có thể được tạo. Các mức tối ưu hóa cao hơn đánh đổi hiệu năng thời gian biên dịch cho hiệu năng thời gian chạy. Mức tối ưu hóa không thể được đặt lớn hơn -1 nếu gói tối ưu hóa không tồn tại trong thời gian chạy.

TraceMonkey :

TraceMonkey bổ sung quá trình biên dịch mã gốc vào công cụ JavaScript® của Mozilla (được biết đến với tên là Spider SpiderMonkey,). Nó dựa trên một kỹ thuật được phát triển tại UC Irvine có tên là cây dấu vết, và xây dựng mã và ý tưởng được chia sẻ với dự án Tamarin Trace. Kết quả cuối cùng là sự gia tăng tốc độ lớn cả về nội dung trang chrome và trang web của trình duyệt.

VM JavaScript JavaScript được sử dụng trong Chrome không bao gồm trình thông dịch. Thay vào đó, nó bao gồm hai trình biên dịch và biên dịch mã khi đang bay. Một trong những trình biên dịch chạy nhanh nhưng tạo ra mã không hiệu quả, cái còn lại là trình biên dịch tối ưu hóa.

Tôi có thể hiểu tại sao một số người sẽ coi đây là "gian lận", vì V8 lấy mã nguồn làm đầu vào mỗi khi mã chạy và người dùng phải cài đặt V8. Nhưng hãy xem xét một trình biên dịch phát ra một tệp thực thi bao gồm một trình thông dịch và mã byte hoàn chỉnh. Sau đó, bạn sẽ có một chương trình độc lập. Nó sẽ không rất hiệu quả.

Sự xuất hiện của trình biên dịch JIT cho các ngôn ngữ script đã làm mờ ranh giới giữa biên dịch và giải thích đến một điểm mà câu hỏi không có nghĩa gì nhiều. Có phải nó chỉ giải thích khi động cơ đọc một dòng mã và ngay lập tức thực thi nó? (Các tập lệnh Shell vẫn thường được triển khai theo cách này.) Có phải là diễn giải khi công cụ lấy toàn bộ tệp, ngay lập tức biên dịch nó thành một số mã byte và sau đó diễn giải mã byte? (Công cụ Mozilla giai đoạn đầu hoạt động theo cách này, cũng như CPython.) Có phải nó diễn giải khi công cụ phân tích cú pháp một chức năng tại một thời điểm và JIT biên dịch nó thành mã gốc? Thế còn những công cụ biên dịch toàn bộ tệp thành mã byte, sau đó JIT một chức năng tại một thời điểm khi cần thiết thì sao? (Hầu hết các công cụ script ngày nay hoạt động theo cách này,

Có nhiều sắc thái giữa biên dịch và giải thích.

Tôi nghĩ định nghĩa hữu ích nhất để giải thích là "được cung cấp mã nguồn của chương trình tại thời điểm thực hiện, không có bước trước thời gian riêng biệt". Theo định nghĩa này, tất cả các công cụ JavaScript là thông dịch viên. Nhưng đây chắc chắn không phải là định nghĩa duy nhất có thể có của giải thích.

Nhưng JavaScript có được thiết kế để giải thích không? Theo một cách nào đó, có: nó có một evalhàm cũng như hàm Functiontạo mà bạn có thể cung cấp mã chương trình dưới dạng một chuỗi sẽ được thực thi. Khả năng tự động xây dựng mã chương trình trong thời gian chạy yêu cầu công cụ có khả năng diễn giải mã nguồn. Nhưng điều này không có nghĩa là bạn không thể làm mọi thứ khác trước thời hạn. Ngay cả trong một ngôn ngữ được biên dịch như C ++ và C #, bạn có thể lấy mã nguồn, biên dịch nó trong bộ nhớ sang mã máy mới và sau đó thực thi điều đó. Thậm chí còn có các thư viện cho điều đó: LLVM + Clang trong C ++ và dự án Roslyn trong C #.

Ngoài ra, cơ chế phân phối cho JavaScript là mã nguồn; không có dạng mã byte được công nhận của nó. C # và Java có mã byte chính thức của họ và mọi người đều mong đợi C ++ sẽ được phân phối dưới dạng mã máy. Nhưng đây vẫn không phải là một khía cạnh vốn có nếu ngôn ngữ, chỉ là một kịch bản sử dụng chi phối. Trên thực tế, ActionScript tương đối gần của JavaScript trong Flash trên thực tế được phân phối dưới dạng mã byte (trình biên dịch Flash biên dịch trước tất cả các tập lệnh).

Không có sự đồng ý hoàn toàn theo định nghĩa 'giải thích' so với 'được biên dịch'. Trong phân biệt cổ điển, các ngôn ngữ được biên dịch tạo ra một tệp thực thi nhị phân độc lập, trong khi các ngôn ngữ được giải thích yêu cầu thời gian chạy được triển khai để thực thi mã. Máy ảo, mã byte và như vậy làm mờ sự khác biệt.

Nhưng đây là một định nghĩa có thể hữu ích: Ngôn ngữ được diễn giải là ngôn ngữ mà thời gian chạy ngôn ngữ tiêu chuẩn có thể lấy văn bản mã nguồn làm đầu vào và thực thi nó. Theo định nghĩa đó Perl, Python, Ruby, JavaScript và shell script và những thứ tương tự được diễn giải (ngay cả khi chúng sử dụng các bước trung gian như mã byte hoặc thậm chí mã gốc). Java, C #, C, v.v. Và JavaScript theo định nghĩa được diễn giải, ngay cả khi thông số kỹ thuật không sử dụng từ chính xác.