2008-10-12 27 views
6

Sau khi chuyển đổi qua lại giữa một số ngôn ngữ kịch bản trong tuần này, tôi thấy mình đang suy nghĩ về sự tương đồng của chúng. Tuy nhiên, tôi luôn luôn tiếp cận với Google (hoặc ngày nay SO) để ghi nhớ các chi tiết như những gì tương đương cục bộ của "instanceof" và "endswith" là, hoặc cú pháp đúng để khai báo một giao diện, hoặc bất cứ thứ gì.những gì sẽ là những trở ngại để tạo ra một ngôn ngữ kịch bản phổ quát kiểu "Europanto"?

Điều này nhắc tôi về ngôn ngữ (con người) Europonto. Chỉ cần chọn một số cú pháp tiếng Anh mơ hồ và một số từ điển Lãng mạn/Germanic/Slavic, và tất cả đều tốt!

Vậy điều gì sẽ xảy ra nếu chúng tôi cố gắng làm điều tương tự với ngôn ngữ kịch bản. Trong tâm trạng cho các khối thụt lề kiểu Python ngày nay? Khỏe! Bạn muốn sử dụng một đối tượng nguyên mẫu? Được! Chỉ có thể nhớ cách đánh vần tên PHP của một số chức năng thư viện? Không vấn đề gì!

Dù sao, đó là ý tưởng hoang dã và điên rồ. Vì chúng ta cần một câu hỏi thừa nhận câu trả lời cụ thể, hãy thắt chặt nó như sau:

Điều gì sẽ là xung đột quan trọng nhất trong việc tạo ngôn ngữ kịch bản cho phép tất cả cú pháp và chức năng thư viện gốc của [Python, Ruby, PHP, Perl, shell và JavaScript], sao cho bạn có thể tự do trộn các khối mã và tên hàm giữa các ngôn ngữ?

Và giả sử rằng bất kỳ công trình xây dựng cụ thể nào phải nhất quán ở cấp tuyên bố. Vì vậy, chúng tôi sẽ cho phép:

foreach($foo as $bar) 
{ 
    if $foo == 2: 
     print "hi" 
} 

nhưng không, nói,

foreach($foo as $bar) 
{ 
    if $foo == 2: 
     print "hi" 
    endif 
end 

Xung đột có thể bao gồm: sự mơ hồ phân tích cú pháp; va chạm tên; các ngữ nghĩa xung đột cho các đối tượng hoặc chức năng hoặc các bao đóng; vv Tôi đoán rằng phạm vi sẽ là một vấn đề ginormous, nhưng bạn nói với tôi.

Tôi sẽ bắt đầu hoạt động này dưới dạng "wiki cộng đồng", vì vậy nếu bạn nghĩ đó là một câu hỏi thú vị nhưng muốn làm cho nó trở nên khắt khe hơn, hãy chỉnh sửa.

+0

Không bao giờ thấy Europanto trước đây. Rất buồn cười, tôi có thể đọc rất nhiều ngay lập tức. Nhờ để chia sẻ liên kết ;) – OregonGhost

Trả lời

3

Tôi sẽ đề xuất rằng vấn đề chính là nhận ra cú pháp của mỗi câu lệnh được cho là như thế nào.

Trong mọi trường hợp, điểm là gì? Hầu như tất cả các ngôn ngữ kịch bản đều có cơ sở để làm nhiều việc giống nhau, đó là lý do tại sao mọi người có khuynh hướng làm chủ một thứ mà họ sử dụng một cách nhất quán và gắn bó với nó.

0

Tôi đã bắt đầu thấy cú pháp đó chỉ là một thuộc tính của một ngôn ngữ. Và hầu hết trong số họ trông giống như C với tôi. Mục đích của một ngôn ngữ (hướng đối tượng, gõ mạnh mẽ, vv) là một cái gì đó khác một lần nữa. Nó bắt đầu trông giống như cú pháp không phải là khía cạnh quan trọng nhất.

tôi đã đi và đọc mục wikipedia ...

Europanto là một jest ngôn ngữ trình bày như một "ngôn ngữ xây dựng" với một vốn từ vựng Hodge-người mập và lùn

"Hodge-người mập và lùn" âm thanh giống như cách Perl đã được mô tả cho tôi!

0

Tôi đã tìm thấy rather detailed discussion of closures in Ruby. Có vẻ như hành vi của Ruby cùng tồn tại với JavaScript hoặc Python sẽ đòi hỏi một số định dạng xấu.

Nếu có ai thêm Perl vào danh sách ngôn ngữ được đề cập, tôi nghĩ rằng các quy tắc phạm vi từ vựng của nó sẽ trình bày một vấn đề liên quan?

1

Khó khăn chính là để cho phép mọi người duy trì nó. Với ngôn ngữ được xác định rõ, bạn chỉ có thể print một cách nhất định và thực hiện sys.argv một cách nhất định. một khi bạn cho phép nhiều cú pháp, không có cách nào sane để tìm kiếm tất cả các sys.argv trong cơ sở mã bạn có.

1

Ở mức mức độ mức độ vấn đề duy nhất tôi có thể thấy là phát hiện khối nào có cú pháp nào, sau đó tách chúng ra và phân tích chúng bằng các trình phân tích cụ thể. Tất nhiên với những tuyên bố rất nhỏ có thể có sự mơ hồ về ngôn ngữ của nó và bạn có thể tranh luận rằng nó không quan trọng, nhưng nó có thể là trường hợp, rằng trong các ngôn ngữ khác nhau cùng một chuỗi ký tự khác nhau như vậy này có thể là một vấn đề tinh tế.

Ở mức API, bạn sẽ có nhiều phương pháp khác nhau để thực hiện điều tương tự nhưng theo cách khác hoặc cách thức khác để thực hiện. Vì vậy, ví dụ bạn có thể không có cách nào để làm Java của string.startsWith() trong PHP, vì vậy bạn sẽ làm một cái gì đó khác nhau, hoặc không có cách nào để làm PHP strstr() (trả về một phần của chuỗi từ kim tìm thấy đến cùng) và bạn sẽ thực hiện điều gì đó khác biệt cho điều đó hoặc thậm chí suy nghĩ khác nhau về vấn đề. Sau đó, bạn sẽ phải có tất cả các phương pháp API khác nhau để thực hiện những điều tương tự và đó sẽ là API rất lớn để triển khai, hỗ trợ và (không cho phép) tìm hiểu.

Ở mức wetware mức mã do người khác viết sẽ hoàn toàn không đọc được trừ khi bạn biết nhiều ngôn ngữ và sự khác biệt tinh tế của chúng. Tôi nghĩ rằng thật khó để học một ngôn ngữ lập trình đơn với các chi tiết nhỏ nhất và do đó, không có gì là thiết thực để có loại quái vật frankensteinish này được tạo ra. Tôi có thể nghĩ về một ngoại lệ để sử dụng như một ngôn ngữ mô tả thuật toán mà nó đã được sử dụng trong các trường đại học trên toàn thế giới, nơi giáo viên có một số ngôn ngữ theo ý thích của mình và làm cho mã có thể đọc được vì nó có thể cho con người mà không cần phải thực hiện một trình phân tích cú pháp cho nó.

Như một mặt lưu ý tôi nghĩ loại hệ thống này có thể là thực hiện tại nỗ lực ít nhất bằng bằng cách nào đó sử dụng CLR NET, nơi bạn có một tấn của các ngôn ngữ khác nhau mỗi biên dịch để bytecode cùng và truy cập vào các biến tương tự và công cụ. Tất cả những gì bạn cần làm là chia mã thành các cụm ngôn ngữ khác nhau, sau đó biên dịch chúng riêng biệt trên trình biên dịch tương ứng của chúng và sau đó chỉ cần hợp nhất bytecode và bằng cách nào đó đảm bảo tất cả đều trỏ đến cùng các biến và hàm khi đề cập cùng tên trên các ngôn ngữ khác nhau.

Các vấn đề liên quan