LL과 LR 파싱을 여러 가지 기준으로 대조하겠습니다.

복잡성

LL이 이겼습니다. LL 파서를 손으로 쉽게 작성할 수 있습니다. 실제로 이것은 일반적으로 수행됩니다. Microsoft C # 컴파일러는 수동으로 작성된 재귀 강하 파서입니다 ( 여기서 소스 는 Patrick Kristiansen이 작성한 주석을 찾으십시오-블로그 게시물도 매우 흥미 롭습니다).

LR 구문 분석은 다소 직관적이지 않은 방법으로 텍스트를 구문 분석합니다. 작동하지만 정확히 작동하는 방식으로 머리를 감싸는 데 시간이 걸렸습니다. 따라서 이러한 파서를 직접 작성하는 것은 어렵습니다. LR 파서 생성기를 구현하는 것이 다소 쉬울 것입니다.

대부분

LR이 승리합니다. 모든 LL 언어는 LR 언어이지만 LL 언어보다 많은 LR 언어가 있습니다 (언어는 LL 파서로 구문 분석 할 수있는 경우 LL 언어이며 구문 분석 할 수있는 언어는 LR 언어 임) LR 파서).

LL은 꽤 많은 불편이 됩니다 다만 어떤 프로그래밍 언어에 대해 구현할 때 당신을 귀찮게합니다. 개요는 여기 를 참조 하십시오 .

LR 언어가 아닌 모호한 언어가 있지만 그 언어는 매우 드 rare니다. 당신은 그런 언어를 거의 만나지 않습니다. 그러나 LALR에는 몇 가지 문제가 있습니다.

LALR은 LR 파서가 테이블을 더 작게 만드는 해킹입니다. LR 파서의 테이블은 일반적으로 엄청나게 커질 수 있습니다. LALR 파서는 더 작은 테이블과 교환하여 모든 LR 언어를 구문 분석하는 기능을 포기합니다. 대부분의 LR 파서는 실제로 LALR을 사용합니다 (비밀하게는 아니지만 구현하는 것을 정확하게 찾을 수 있습니다).

LALR은 교대 감소 및 감소 감소 갈등에 대해 불평 할 수 있습니다. 이것은 테이블 핵으로 인해 발생합니다. 유사한 항목을 ‘접습니다’. 대부분의 항목이 비어 있기 때문에 작동하지만 비어 있지 않으면 충돌이 발생합니다. 이러한 종류의 오류는 자연스럽지 않고 이해하기 어렵고 수정은 일반적으로 매우 이상합니다.

컴파일러 오류 및 오류 복구

LL이 이겼습니다. LL 구문 분석에서, 특히 손으로 쓴 구문 분석기에서 유용한 컴파일러 오류를 발생시키는 것은 일반적으로 매우 쉽습니다. 당신은 다음에 무엇을 기대하는지 알기 때문에, 그렇지 않으면, 무엇이 잘못되었는지 그리고 가장 현명한 오류가 무엇인지 알게됩니다.

또한 LL 구문 분석에서 오류 복구가 훨씬 쉽습니다. 입력이 올바르게 구문 분석되지 않으면 약간 건너 뛰고 나머지 입력이 올바르게 구문 분석되는지 알아볼 수 있습니다. 예를 들어 일부 프로그래밍 문의 형식이 잘못된 경우 계속 건너 뛰고 다음 문을 구문 분석하여 둘 이상의 오류를 포착 할 수 있습니다.

LR 파서를 사용하면 훨씬 어렵습니다. 잘못된 입력을 받아들이고 문제가 발생한 영역에서 오류를 인쇄하도록 문법을 보강하려고 시도 할 수 있지만 일반적으로 수행하기가 매우 어렵습니다. 비 LR (또는 비 LALR) 문법으로 끝날 가능성도 높아집니다.

속도

속도는 실제로 입력 (LL 또는 LR)을 구문 분석하는 방식의 문제가 아니라 결과 코드의 품질과 테이블 사용 (LL 및 LR 모두에 테이블을 사용할 수 있음)입니다. 따라서 LL과 LR은 이와 관련하여 비교할 수 있습니다.

모래밭

다음 은 LL과 LR을 대조하는 사이트에 대한 링크입니다. 바닥 근처의 섹션을 찾으십시오.

여기서 차이점에 관한 대화를 찾을 수 있습니다. 거기에서 발언되는 의견을 비판적으로 보는 것은 나쁜 생각이 아닙니다. 거기에는 약간의 거룩한 전쟁이 진행되고 있습니다.

자세한 내용을 보려면 여기 와 여기 에 파서에 대한 내 게시물 중 두 가지가 있지만 LL과 LR의 대비는 엄격하지 않습니다.

답변