모호한 문법 또는 프로덕션 규칙은 언제 확인됩니까? (들소 이동/경고 감소)

Question

이동/축소 오류를 해결하는 데 필요한 문서와 하우투는 분명 많습니다. 들소 박사는 올바른 해결책은 대개 단지 그들을 기대하고 그것에 대처하는 것이라고 제안합니다. 이 같은 일이있을 때

:

는

S: S 'b' S | 't' 

당신은 쉽게 다음과 같이이를 해결할 수 있습니다

S: S 'b' T | T 
T: 't' 

내 질문은 : 터치가 모호 % 기대 문법을두고하는 것이 좋습니다 교대/축소 문제를 피하거나 문법을 조정하여 문제를 피하는 것이 더 좋습니까? 나는 거기에 균형이 있다고 생각하고 저자의 필요에 근거하고 있지만, 나는 정말로 모른다.

Answer 1

내가 읽었을 때 귀하의 질문은 "모호한 문법 또는 제작 규칙이 언제 적용됩니까?"입니다.

먼저 설명하는 언어를 고려하십시오. 언어에 모호한 제작 규칙을 허용한다는 의미는 무엇입니까?

귀하의 예는 같은 표현이 포함될 수 있습니다 언어에 대해 설명합니다 ((((t) b t) b t) b t) 될 두 번째 예에서와 같이 해결 t b t b t b t

표현을하지만, 모호한 문법에도 될 수를 (t b (t b (t b (t)))) 또는 (t b t) b (t b t). 유효 할 수있는 언어는 언어에 따라 다를 수 있습니다. b 연산자 모델 빼기가 실제로 모호하지 않아야하지만 추가 된 경우 괜찮을 수도 있습니다. 이것은 언어에 따라 다릅니다.

고려해야 할 두 번째 질문은 충돌이 해결 된 후 결과 문법 소스 파일이 어떻게 보이는지에 대한 것입니다. 다른 소스 코드와 마찬가지로 문법은 사람이 읽고, 또한 컴퓨터를 통해 읽을 수도 있습니다. 구문 분석기가 문법에서 무엇을하려하는지 명확하게 설명하는 표기법을 선호하십시오. 즉, 구문 분석기가 정의되지 않은 동작 (예 : 열의 언어로 함수 인수를 평가하는 순서)을 실행하는 경우 문법 은 희미하게 보입니다.이 모호합니다.

Answer 2

운영자 우선 순위로 충돌 해결을 안내 할 수 있습니다. 'b'을 왼쪽 또는 오른쪽 연관 연산자로 선언하고 최소한이 경우를 다뤘습니다.

더 복잡한 패턴의 경우 최종 파서가 모든 경우에 올바른 결과를 생성하는 한 경고는 그리 걱정할 필요가 없습니다. 선언문을 사용하여 올바른 결과를 얻을 수 없다면 문법을 다시 작성해야합니다.

Answer 3

내 컴파일러 과정에서 지난 학기에 bison을 사용하고 파스칼의 하위 집합에 대한 컴파일러를 만들었습니다.

언어가 충분히 복잡하면 약간의 오류가 발생합니다. 그들이 왜 거기에 있는지, 그리고 그것을 제거하기 위해해야 ​​할 일을 이해한다면, 우리는 그것이 괜찮은 것으로 판명되었습니다. 무언가가 있었지만 그 행동으로 인해 우리가 원했던 것처럼 작동하고, 많은 생각과 노력을 필요로하면서 (또한 문법을 ​​복잡하게 만들 때), 우리는 혼자 남겨 두었습니다. 오류를 완전히 이해하고 어딘가에 문서화하여 (심지어 혼자서도) 문서화하십시오. 그러면 여러분은 항상 그 오류의 상황을 알 수 있습니다.

일이 실제로 복잡해지면 비용/이점 분석이 필요하지만 IMHO는이를 먼저 고려해야하며 실제로 작업이 무엇인지 파악해야합니다. (그리고 그 작업이 다른 것을 깨뜨리거나 다른 것을 어렵게 만드는 경우) , 그리고 거기에서 가라. 평상시처럼 절대 건드리지 마십시오.

Answer 4

문법이 모호하지 않다는 것을 증명해야 할 때 나는 먼저 Parsing Expression Grammar으로 작성한 다음 프로젝트 요구 사항에 맞게 도구 세트로 설정 한 문법 유형으로 직접 변환하는 경향이 있습니다. 내 경험상,이 수준의 증거에 대한 필요성은 매우 드뭅니다. 대부분의 시프트/줄이기 충돌은 (예를 들어 순서대로) 정확성을 보여주기 위해 상당히 사소한 것이었기 때문입니다.