나는 과거에 다양한 프로젝트, 일반적으로 번역자 (예 : EDA 앱으로 스트리밍 된 EDIF의 하위 집합)에 lex 및 yacc (보다 일반적으로 들소)를 사용했습니다. 또한 수십 년 전의 lex / yacc 문법을 기반으로 한 코드를 지원해야했습니다. 그래서 나는 전문가가 아니지만 도구를 둘러싼 길을 알고 있습니다.
과거에 다양한 포럼에서 Antlr에 대한 긍정적 인 의견을 보았으며, 내가 잃어버린 것이 궁금합니다. 둘 다 사용했다면 Antlr에서 더 나아진 것이 무엇인지 알려주십시오. 현재 제약 조건은 C ++ 상점에서 일하는 것이며 우리가 제공하는 모든 제품에는 Java가 포함되지 않으므로 결과 파서는 해당 규칙을 따라야합니다.
답변:
하나의 주요 차이점은 ANTLR이 LL (*) 파서를 생성하는 반면 YACC와 Bison은 모두 LALR 인 파서를 생성한다는 것입니다. 이것은 여러 응용 프로그램에서 중요한 차이점이며 가장 명백한 연산자는 다음과 같습니다.
expr ::= expr '+' expr
| expr '-' expr
| '(' expr ')'
| NUM ;ANTLR은이 문법을 그대로 처리 할 수 없습니다. ANTLR (또는 다른 LL 파서 생성기)을 사용하려면이 문법을 왼쪽 재귀가 아닌 것으로 변환해야합니다. 그러나 Bison은이 형식의 문법에 문제가 없습니다. '+'와 '-'를 왼쪽 연관 연산자로 선언해야하지만 왼쪽 재귀에 반드시 필요한 것은 아닙니다. 더 좋은 예는 다음과 같습니다.
expr ::= expr '.' ID '(' actuals ')' ;
actuals ::= actuals ',' expr | expr ;규칙 expr과 actuals규칙은 모두 재귀 적입니다. 이렇게하면 여러 레지스터가 필요하지 않고 불필요한 유출이 발생하지 않기 때문에 코드 생성 시간이되면 훨씬 효율적인 AST가 생성됩니다 (왼쪽 기울임 트리는 축소 될 수 있지만 오른쪽 기울임 트리는 축소 할 수 없음).
개인적 취향 측면에서 LALR 문법은 구성하고 디버깅하기가 훨씬 쉽다고 생각합니다. 단점은 시프트 감소 및 (두려운) 감소와 같은 다소 복잡한 오류를 처리해야한다는 것입니다. 이는 파서가 파서를 생성 할 때 포착하는 오류이므로 최종 사용자 경험에는 영향을 미치지 않지만 개발 프로세스를 좀 더 흥미롭게 만들 수 있습니다. ANTLR은 일반적으로 YACC / Bison보다 사용하기 쉬운 것으로 간주됩니다.
YACC / Bison과 ANTLR의 가장 큰 차이점은 이러한 도구가 처리 할 수있는 문법 유형입니다. YACC / Bison은 LALR 문법을 처리하고 ANTLR은 LL 문법을 처리합니다.
LALR 문법을 오랫동안 사용해온 사람들은 종종 LL 문법을 다루는 것이 더 어렵다는 것을 알게 될 것입니다. 그렇다고 문법이나 도구가 본질적으로 다루기가 더 어렵다는 것을 의미하지는 않습니다. 사용하기 쉬운 도구는 주로 문법 유형에 익숙합니다.
장점이있는 한, LALR 문법이 LL 문법보다 유리한 측면이 있으며 LL 문법이 LALR 문법보다 유리한 다른 측면이 있습니다.
YACC / Bison은 테이블 구동 파서를 생성하는데, 이는 "프로세싱 로직"이 파서 프로그램의 데이터에 포함되고 파서의 코드에는 포함되지 않음을 의미합니다. 매우 복잡한 언어에 대한 파서조차도 비교적 작은 코드 풋 프린트 (footprint)를 갖는다는 점이 장점이다. 이것은 하드웨어가 매우 제한적인 1960 년대와 1970 년대에 더 중요했습니다. 테이블 기반 파서 생성기는이 시대로 거슬러 올라 갔으며 당시에는 작은 코드 공간이 주요 요구 사항이었습니다.
ANTLR은 재귀 강하 파서를 생성하는데, 이는 문법의 각 생성 규칙이 파서 코드의 함수로 표현되므로 "프로세싱 로직"이 파서의 코드에 포함되어 있음을 의미합니다. 그 대가는 코드를 읽어 파서가하는 일을 이해하기 쉽다는 것입니다. 또한 재귀 강하 파서는 일반적으로 테이블 구동 파서보다 빠릅니다. 그러나 매우 복잡한 언어의 경우 코드 풋 프린트가 더 커집니다. 이것은 1960 년대와 1970 년대의 문제였습니다. 당시에는 하드웨어 제한 때문에 Pascal과 같은 비교적 작은 언어 만 이런 식으로 구현되었습니다.
ANTLR 생성 파서는 일반적으로 10.000 줄의 코드 이상에 있습니다. 필기 재귀 하강 파서는 종종 같은 야구장에 있습니다. Wirth의 Oberon 컴파일러는 코드 생성을 포함하여 약 4000 줄의 코드를 가진 가장 컴팩트 한 컴파일러 일 것입니다. 그러나 Oberon은 약 40 개의 생산 규칙을 가진 매우 컴팩트 한 언어입니다.
누군가 이미 지적했듯이 ANTLR의 큰 장점은 ANTLRworks라는 그래픽 IDE 도구입니다. 완벽한 문법 및 언어 디자인 연구소입니다. 입력 할 때 문법 규칙을 시각화하고 충돌이 발견되면 충돌이 무엇인지, 그리고 그 원인을 그래픽으로 보여줍니다. 심지어 왼쪽 재귀와 같은 충돌을 자동으로 리팩토링하고 해결할 수도 있습니다. 충돌이없는 문법이 있으면 ANTLRworks가 언어의 입력 파일을 구문 분석하고 구문 분석 트리와 AST를 빌드하고 IDE에 그래픽으로 트리를 표시 할 수 있습니다. 이는 많은 시간을 절약 할 수 있기 때문에 매우 큰 이점입니다. 코딩을 시작하기 전에 언어 디자인에서 개념적 오류를 발견 할 수 있습니다! LALR 문법에 해당하는 도구를 찾지 못했습니다. 해당 도구가없는 것 같습니다.
파서를 생성하지 않고 직접 코드를 작성하려는 사람들에게도 ANTLRworks는 언어 디자인 / 프로토 타이핑을위한 훌륭한 도구입니다. 가능한 최고의 도구 일 것입니다. 불행히도 LALR 파서를 작성하려는 경우 도움이되지 않습니다. 단순히 ANTLRworks를 활용하기 위해 LALR에서 LL로 전환하는 것이 가치가있을 수 있지만 일부 사람들에게는 문법 유형 전환이 매우 고통스러운 경험이 될 수 있습니다. 다시 말해 YMMV입니다.
ANTLR의 몇 가지 장점 :
내 .02 $
ANTRL의 또 다른 장점은 당신이 사용할 수 있다는 것입니다 ANTLRWORKS을 유사한 다른 발전을위한 도구뿐만 아니라이있을 수 있기 때문에 나는이 엄격한 장점이라고 말할 수는 없지만,.
들소 / 플렉스 메모리 사용량은 일반적으로 1MB 정도입니다. antlr과는 대조적으로-파싱하려는 파일의 모든 토큰에 대해 512 바이트의 메모리를 사용한다고 가정합니다. 4 백만 개의 토큰이 있고 32 비트 시스템에서 가상 메모리가 부족합니다.
구문 분석하려는 파일이 크면 antlr에 메모리가 부족할 수 있으므로 구성 파일을 구문 분석하려는 경우 실행 가능한 솔루션이됩니다. 그렇지 않으면 데이터가 많은 파일을 구문 분석하려면 Bison을 시도하십시오.