Tại sao ngữ pháp mơ hồ xấu?

Tôi hiểu rằng nếu tồn tại 2 hoặc nhiều cây phái sinh trái hoặc phải, thì ngữ pháp là mơ hồ, nhưng tôi không thể hiểu tại sao nó tệ đến mức mọi người đều muốn loại bỏ nó.

Hãy xem xét ngữ pháp sau cho các biểu thức số học: Hãy xem xét biểu thức sau: Giá trị của nó là gì? Đây là hai cây phân tích có thể:

Theo cái bên trái, chúng ta nên hiểu là , đó là cách giải thích thông thường. Theo người bên phải, chúng ta nên hiểu nó là , có lẽ không phải là mục đích.$a-b-c$$(a-b)-c$$a-(b-c) = a-b+c$

Khi biên dịch một chương trình, chúng tôi muốn việc giải thích cú pháp không rõ ràng. Cách dễ nhất để thực thi điều này là sử dụng một ngữ pháp rõ ràng. Nếu ngữ pháp không rõ ràng, chúng ta có thể cung cấp các quy tắc ngắt kết nối, như quyền ưu tiên của toán tử và tính kết hợp. Các quy tắc này có thể được thể hiện tương đương bằng cách làm cho ngữ pháp không rõ ràng theo một cách cụ thể.

Cây phân tích cú pháp được tạo bằng cách sử dụng trình tạo cây cú pháp .

Ngược lại với các câu trả lời hiện có khác [ 1 , 2 ], thực sự có một lĩnh vực ứng dụng, trong đó các ngữ pháp mơ hồ rất hữu ích . Trong lĩnh vực xử lý ngôn ngữ tự nhiên (NLP), khi bạn muốn phân tích ngôn ngữ tự nhiên (NL) bằng ngữ pháp chính thức, bạn đã gặp vấn đề là NL vốn đã mơ hồ ở các cấp độ khác nhau [được chuyển thể từ Koh18, ch. 6.4]:

• Cú pháp tổng hợp:

  Peter đuổi theo người đàn ông trong chiếc xe thể thao màu đỏ

  Là Peter hay người đàn ông trong chiếc xe thể thao màu đỏ?

• Ngữ nghĩa ngữ nghĩa:

  Peter đã đến ngân hàng

  Một ngân hàng để ngồi hoặc một ngân hàng để rút tiền từ đâu?

• Thực dụng ambuigity:

  Hai người đàn ông mang hai cái túi

  Họ đã mang các túi cùng nhau hoặc mỗi người đàn ông mang hai túi?

Các cách tiếp cận khác nhau cho NLP đối phó khác nhau với việc xử lý nói chung và đặc biệt là các hoạt động này. Ví dụ: đường ống của bạn có thể trông như sau:

1. Phân tích cú pháp NL với ngữ pháp mơ hồ
2. Đối với mọi AST kết quả: chạy thế hệ mô hình để tạo ra ý nghĩa ngữ nghĩa mơ hồ và loại trừ sự mơ hồ cú pháp không thể từ bước 1
3. Đối với mọi mô hình kết quả: lưu nó trong bộ nhớ cache của bạn.

Bạn làm đường ống này cho mỗi câu. Càng nhiều văn bản, từ cùng một cuốn sách bạn xử lý, bạn càng có thể loại trừ các mô hình không cần thiết, tồn tại cho đến bước 3, từ các câu trước.

Trái ngược với ngôn ngữ lập trình, chúng ta có thể đưa ra yêu cầu rằng mỗi câu NL đều có ngữ nghĩa chính xác. Thay vào đó, chúng ta chỉ có thể ghi sổ nhiều mô hình ngữ nghĩa có thể trong suốt quá trình phân tích các văn bản lớn hơn. Từ lúc này đến lúc khác, những hiểu biết sau này giúp chúng ta loại trừ những sự mơ hồ trước đó.

Nếu bạn muốn làm bẩn tay với các trình phân tích cú pháp có thể tạo ra nhiều dẫn xuất cho ngữ pháp mơ hồ, hãy xem Khung ngữ pháp . Ngoài ra, [Koh18, ch. 5] có phần giới thiệu về nó cho thấy một cái gì đó tương tự như đường ống của tôi ở trên. Lưu ý rằng vì [Koh18] là các ghi chú bài giảng, các ghi chú có thể không dễ hiểu nếu không có các bài giảng.

Tài liệu tham khảo

[Koh18]: Michael Kohlhase. "Xử lý ngôn ngữ tự nhiên dựa trên logic. Học kỳ mùa đông 2018/19. Ghi chú bài giảng." URL: https://kwarc.info/teaching/LBS/notes.pdf . URL của mô tả khóa học: https://kwarc.info/cifts/lbs/ (bằng tiếng Đức)

[Koh18, ch. 5]: Xem chương 5, "Thực hiện các đoạn: Khung ngữ pháp và logic", trong [Koh18]

[Koh18, ch. 6.4] Xem chương 6.4, "Vai trò tính toán của sự mơ hồ", trong [Koh18]

Ngay cả khi có một cách được xác định rõ để xử lý sự mơ hồ (ví dụ biểu thức mơ hồ là lỗi cú pháp), các ngữ pháp này vẫn gây ra sự cố. Ngay khi bạn giới thiệu sự mơ hồ vào một ngữ pháp, một trình phân tích cú pháp có thể không còn chắc chắn rằng trận đấu đầu tiên mà nó nhận được là dứt khoát. Nó cần phải tiếp tục thử tất cả các cách khác để phân tích một tuyên bố, để loại trừ bất kỳ sự mơ hồ nào. Bạn cũng không phải đối phó với một thứ đơn giản như ngôn ngữ LL (1), vì vậy bạn không thể sử dụng trình phân tích cú pháp đơn giản, nhỏ, nhanh. Ngữ pháp của bạn có các ký hiệu có thể được đọc theo nhiều cách, vì vậy bạn phải chuẩn bị để quay lại rất nhiều.

Trong một số miền bị hạn chế, bạn có thể thoát khỏi việc chứng minh rằng tất cả các cách có thể để phân tích một biểu thức là tương đương (ví dụ: vì chúng đại diện cho một hoạt động kết hợp). (a + b) + c = a + (b + c).

Có IF a THEN IF b THEN x ELSE ynghĩa là

IF a THEN
    IF b THEN
        x
    ELSE
        y

hoặc là

IF a THEN
    IF b THEN x
ELSE
    y

? AKA vấn đề khác lơ lửng .

Lấy ví dụ phân tích nhiều nhất trong C ++ chẳng hạn:

bar foo(foobar());

Đây có phải là khai báo hàm fookiểu bar(foobar())(tham số là con trỏ hàm trả về a foobar) hay khai báo biến fookiểu intvà được khởi tạo với khởi tạo mặc định foobar?

Điều này được phân biệt trong các trình biên dịch bằng cách giả sử đầu tiên trừ khi biểu thức bên trong danh sách tham số không thể được hiểu là một kiểu.

Khi bạn nhận được một biểu thức mơ hồ như vậy, trình biên dịch có 2 tùy chọn

1. giả sử rằng biểu thức là một dẫn xuất cụ thể và thêm một số từ chối vào ngữ pháp để cho phép các dẫn xuất khác được thể hiện.

2. lỗi và yêu cầu định hướng một trong hai cách

Cái đầu tiên có thể rơi ra một cách tự nhiên, cái thứ hai đòi hỏi người lập trình trình biên dịch phải biết về sự mơ hồ.

Nếu sự không rõ ràng này không bị phát hiện thì có thể có hai trình biên dịch khác nhau mặc định cho các dẫn xuất khác nhau cho biểu thức mơ hồ đó. Dẫn đến mã là không di động vì lý do không rõ ràng. Điều này dẫn đến mọi người cho rằng đó là một lỗi trong một trong các trình biên dịch trong khi đó thực sự là một lỗi trong đặc tả ngôn ngữ.

Tôi nghĩ rằng câu hỏi chứa một giả định rằng chỉ có đường biên chính xác là tốt nhất.

Trong cuộc sống thực, việc sống với những ngữ pháp mơ hồ là điều khá phổ biến, miễn là chúng không (có thể nói) quá mơ hồ.

Ví dụ: nếu bạn nhìn xung quanh các ngữ pháp được biên dịch bằng yacc (hoặc tương tự, chẳng hạn như bison hoặc byacc), bạn sẽ thấy rằng có khá nhiều cảnh báo về "xung đột N / dịch chuyển" khi bạn biên dịch chúng. Khi yacc gặp phải sự thay đổi / giảm xung đột, điều đó báo hiệu sự mơ hồ trong ngữ pháp.

Tuy nhiên, một sự thay đổi / giảm xung đột thường là một vấn đề khá nhỏ. Trình tạo trình phân tích cú pháp sẽ giải quyết xung đột theo hướng "thay đổi" thay vì giảm. Ngữ pháp là hoàn toàn tốt nếu đó là những gì bạn muốn (và nó dường như hoạt động hoàn toàn tốt trong thực tế).

Xung đột thay đổi / giảm thường phát sinh trong một trường hợp theo thứ tự chung này (sử dụng mũ cho các thiết bị không đầu cuối và chữ thường cho thiết bị đầu cuối):

A -> B | c
B -> a | c

Khi chúng ta gặp phải một c, có một sự mơ hồ: chúng ta nên phân tích ctrực tiếp như một A, hay chúng ta nên phân tích nó như một B, mà đến lượt nó là một A? Trong trường hợp như thế này, yacc và như vậy sẽ chọn tuyến đường đơn giản / ngắn hơn và phân tích cú pháp ctrực tiếp dưới dạng A, thay vì đi tuyến đường c-> B-> A. Điều này có thể sai, nhưng nếu vậy, điều đó có thể có nghĩa là bạn có một lỗi thực sự đơn giản trong ngữ pháp của bạn và bạn không nên cho phép ctùy chọn như một khả năng cho Atất cả.

Bây giờ, ngược lại, chúng ta có thể có một cái gì đó giống như thế này:

A -> B | C
B -> a | c
C -> b | c

Bây giờ khi chúng ta gặp phải một cmâu thuẫn giữa việc nên coi clà a Bhay a C. Có rất ít cơ hội rằng một chiến lược giải quyết xung đột tự động sẽ chọn những gì chúng ta thực sự muốn. Cả hai điều này đều không phải là "sự thay đổi" - cả hai đều là "sự giảm bớt", vì vậy đây là "sự giảm / giảm xung đột" (mà những người quen với yacc và thường nhận ra đó là một vấn đề lớn hơn nhiều so với sự thay đổi / giảm xung đột).

Vì vậy, mặc dù tôi không chắc là tôi đã đi quá xa để nói rằng bất kỳ ai thực sự hoan nghênh sự mơ hồ trong ngữ pháp của họ, trong ít nhất một số trường hợp, nó đủ nhỏ để không ai thực sự quan tâm nhiều về nó. Trong bản tóm tắt, họ có thể thích ý tưởng loại bỏ tất cả sự mơ hồ - nhưng không đủ để luôn thực sự làm điều đó. Ví dụ, một ngữ pháp nhỏ, đơn giản chứa một sự mơ hồ nhỏ có thể thích hợp hơn với một ngữ pháp lớn hơn, phức tạp hơn để loại bỏ sự mơ hồ (đặc biệt là khi bạn đi vào cõi thực tế của việc tạo ra một trình phân tích cú pháp từ ngữ pháp và thấy rằng không rõ ràng ngữ pháp tạo ra một trình phân tích cú pháp sẽ không chạy trên máy mục tiêu của bạn).