문법, 스택, 터미널 기호 및 토큰

Question

파서 (또는 컴파일러)는 일반적으로 입력이되는 알파벳의 일련의 기호에서 특정 토큰 유형을 인식하는 토크 나이저로 구성됩니다.

Google 파서 만 토큰 스트림을 읽습니다. 원시 문자가 아닙니다.

그러나 문법적 계층에서는 터미널 및 비 터미널이 있습니다. 그러나 토큰은 아닙니다.

즉, 문법과 스택 (우리가 LL (k) 또는 LR 패밀리 파서를 사용한다고 가정하자)은 터미널과 비 터미널로 구성됩니다. 그러나 문법적인 관점에서 말하면, 말단 기호에 대한 토큰 유형도 마찬가지로 사용하는 것이 합리적이라고 가정 해 봅시다.

문법 기호 (터미널)를 나타내는 방법 및 일반적으로 "입력 된"터미널이 있습니까?

제 생각에는 인터페이스의 다중 상속이 될 것입니다. 그러나 인터페이스가 실제로 의미가 없도록 하나의 클래스 TokenType 만 있습니다. IGrammarSymbol을 사용하면 터미널 및 비 터미널 (Terminter and Nonterminal) 클래스를 두 개 이상 가질 수 있습니다.이 클래스는 해당 인터페이스를 구현할 수 있습니다.

감사합니다 당신

Answer 1

터미널 또는 비 터미널 모든 문법 기호, 논리적으로 파서의 (다른) 클래스입니다. 서로 다른 "터미널"클래스 또는 다른 "비 터미널"클래스간에 고유 한 유사성이 없으며 이러한 클래스를 "터미널"및 "비 터미널"기본 클래스에서 파생 된 상속 구조로 그룹화하는 것은 거의 의미가 없습니다.

문법 기호의 각 구체적인 인스턴스는 0 개 이상의 속성과 연결됩니다. 속성의 의미 및 유형은 기호의 유형에 따라 결정됩니다. 동일한 기본 유형에서 동일한 (또는 유사한) 속성 콜렉션을 갖는 두 개의 서로 다른 문법 심볼 클래스를 파생시키는 것이 합리적 일 수 있습니다. 예를 들어, 다른 종류의 expression-operator 비 터미널은 모두 기본 하위 클래스 Expression에서 파생 될 수 있습니다. 값 전달 단말기 (식별자 및 리터럴 상수)도이 클래스에서 파생 될 수 있지만 구문 론적 터미널은 의미 속성이없는 클래스에서 파생 될 가능성이 큽니다. (소스 코드 위치와 상관 관계가있는 문법적 속성이 여전히 남아있을 수 있습니다.이 구문 속성은 터미널에만 적용되는 것처럼 보일 수 있지만 비 터미널에서도 구문 속성을 갖는 것이 편리합니다.)