Các công cụ lập trình trực quan, tại sao chúng không làm việc trực tiếp với AST?

Tôi đã tìm thấy một số công cụ lập trình trực quan nguồn mở như Blockly và bạn bè và các dự án khác được lưu trữ tại Github, nhưng không thể tìm thấy bất kỳ công cụ nào hoạt động trực tiếp với cây cú pháp trừu tượng.

Tại sao vậy?

Tôi đang hỏi bởi vì một khi tôi phát hiện ra rằng mọi trình biên dịch ngoài đó đều có một giai đoạn trong quá trình biên dịch, nơi nó phân tích mã nguồn thành AST, rõ ràng với tôi rằng một số công cụ lập trình trực quan có thể lợi dụng điều này để cung cấp cho các lập trình viên để chỉnh sửa AST trực tiếp theo cách trực quan và cũng thực hiện chuyến đi khứ hồi từ nguồn sang nút-đồ thị và sau đó quay lại nguồn khi cần.

Chẳng hạn, người ta có thể nghĩ rằng từ JavaScript AST Visualizer đến một công cụ lập trình trực quan JavaSript thực tế không có quá nhiều sự khác biệt.

Vì vậy, tôi đang thiếu gì?

Nhiều trong số các công cụ này làm việc trực tiếp với cây cú pháp trừu tượng (hay đúng hơn là trực quan một-một trực tiếp về nó). Điều đó bao gồm Blockly, mà bạn đã thấy, và các ngôn ngữ và trình soạn thảo dựa trên khối khác giống như nó ( Scratch , Pencil Code / Dropplet , Snap ! , GP , Tiled Grace , v.v.).

Các hệ thống đó không hiển thị biểu diễn đồ thị đỉnh và cạnh truyền thống, vì các lý do được giải thích ở nơi khác (không gian và độ khó tương tác), nhưng chúng đại diện trực tiếp cho một cây. Một nút, hoặc khối, là con của một nút khác nếu nó trực tiếp, vật lý bên trong cha mẹ.

Tôi đã xây dựng một trong những hệ thống này ( Tiled Grace , giấy , giấy ). Tôi có thể đảm bảo với bạn, nó hoạt động rất nhiều với AST trực tiếp: những gì bạn nhìn thấy trên màn hình là một đại diện chính xác của cây cú pháp, như các phần tử DOM lồng nhau (vì vậy, một cây!).

Đây là AST của một số mã. Root là một nút gọi phương thức "for ... do". Nút đó có một số con, bắt đầu bằng "_ .. _", bản thân nó có hai con, nút "1" và nút "10". Những gì xuất hiện trên màn hình chính xác là những gì trình biên dịch phụ trợ trình bày ở giữa quá trình - về cơ bản là cách hệ thống hoạt động.

Nếu bạn thích, bạn có thể nghĩ về nó như một bố cục cây tiêu chuẩn với các cạnh hướng ra khỏi màn hình về phía bạn (và bị chặn bởi khối phía trước chúng), nhưng lồng nhau là một cách hợp lệ để hiển thị một cây như một đỉnh sơ đồ.

Nó cũng sẽ "thực hiện chuyến đi khứ hồi từ nguồn tới đồ thị nút và sau đó quay lại nguồn khi cần". Trên thực tế, bạn có thể thấy điều đó xảy ra khi bạn nhấp vào "Chế độ xem mã" ở phía dưới. Nếu bạn sửa đổi văn bản, nó sẽ được phân tích lại và cây kết quả được hiển thị để bạn chỉnh sửa lại và nếu bạn sửa đổi các khối, điều tương tự cũng xảy ra với nguồn.

Pencil Code về cơ bản cũng giống như vậy, tại thời điểm này, một giao diện tốt hơn . Các khối mà nó sử dụng là chế độ xem đồ họa của CoffeeScript AST. Các hệ thống dựa trên khối hoặc gạch khác cũng vậy, mặc dù một số trong số chúng không làm cho khía cạnh lồng nhau rõ ràng trong biểu diễn trực quan và nhiều người không có ngôn ngữ văn bản thực sự đằng sau chúng nên " cây cú pháp "có thể là một chút ảo tưởng, nhưng nguyên tắc là có.

Sau đó, điều bạn đang thiếu là các hệ thống này thực sự đang hoạt động trực tiếp với cây cú pháp trừu tượng. Những gì bạn nhìn thấy và thao tác là một kết xuất cây hiệu quả trong không gian, trong nhiều trường hợp theo nghĩa đen là AST, trình biên dịch hoặc trình phân tích cú pháp tạo ra.

Ít nhất hai lý do:

1. Bởi vì mã nguồn là một nhiều đại diện súc tích hơn. Đặt ra một AST như một biểu đồ sẽ chiếm nhiều bất động sản trực quan hơn.

   Các lập trình viên giải thưởng có càng nhiều bối cảnh càng tốt - tức là có càng nhiều mã xuất hiện cùng một lúc trên màn hình cùng một lúc. Bối cảnh giúp họ quản lý tốt hơn sự phức tạp. (Đó là một lý do tại sao nhiều lập trình viên sử dụng các phông chữ nhỏ điên rồ này và màn hình 30 "khổng lồ.)

   Nếu chúng tôi cố gắng hiển thị AST dưới dạng biểu đồ hoặc cây, thì số lượng mã bạn có thể phù hợp trên một màn hình sẽ ít hơn nhiều so với khi nó được biểu thị dưới dạng mã nguồn. Đó là một mất mát lớn cho năng suất của nhà phát triển.

2. AST dành cho lập trình trình biên dịch, không dễ hiểu cho các lập trình viên. Nếu bạn lấy một đại diện AST hiện có và hiển thị nó một cách trực quan, có lẽ các nhà phát triển sẽ khó hiểu hơn, bởi vì AST không được thiết kế để các nhà phát triển dễ học.

   Ngược lại, mã nguồn thường được các nhà phát triển thiết kế để có thể đọc / hiểu được; đó thường là một tiêu chí thiết kế quan trọng cho mã nguồn, nhưng không phải cho AST. AST chỉ cần được hiểu bởi các nhà văn trình biên dịch, không phải bởi các nhà phát triển hàng ngày.

   Và, trong mọi trường hợp, ngôn ngữ AST sẽ là nhà phát triển ngôn ngữ thứ hai phải học, ngoài ngôn ngữ nguồn. Không phải là một chiến thắng.

Xem thêm /software//q/119463/34181 để biết thêm một số lý do tiềm năng.

AST điển hình của trình biên dịch là khá phức tạp và dài dòng. Biểu diễn đồ thị theo hướng sẽ nhanh chóng trở nên khá khó theo dõi. Nhưng có hai khu vực rộng lớn của CS nơi AST được sử dụng.

1. Ngôn ngữ Lisp thực sự được viết là AST. Mã nguồn chương trình được viết dưới dạng danh sách và được trình biên dịch và / hoặc trình thông dịch trực tiếp sử dụng (tùy thuộc vào biến thể nào đang được sử dụng).
2. Các ngôn ngữ mô hình hóa, ví dụ UML và nhiều ngôn ngữ cụ thể trong miền trực quan sử dụng các ký hiệu đồ họa là các hiệu ứng đồ thị cú pháp trừu tượng (ASG) ở mức độ trừu tượng cao hơn so với ngôn ngữ mục đích chung thông thường AST.