해석 이론 노트, 제2부분

이 주제에 대한 내용을 더 많이 읽은 후에, 나는 나의 글 중의 '스캐너와 해석기' 부분을 수정해야 한다는 것을 깨달았다.

어휘와 문법

촘스키 문법의 관점에서 볼 때 어휘 문법과 문법 문법은 차이가 없다.예를 들어 간단한 위영어(조무스키의 형식)를 연구해 보자.

Letter → "a" | "b" | "c" | "d" | "e" | "f" | "g"
Word → Letter | Letter Word
SentencePart → Word | Word " " SentencePart
Sentence → SentencePart "."
TextPart → Sentence | Sentence " " TextPart
Text → TextPart ε
S → Text

이것은 읽기와 사용이 매우 어렵다.다음으로 변경합니다EBNF.

Letter = "a" | "b" | "c" | "d" | "e" | "f" | "g" .
Word = Letter { Letter } .
Sentence = Word { (" " Word) } "." .
Text = Sentence { " " Sentence } .

또는

Letter <- [a-g]
Word <- Letter+
Sentence <- Word (" " Word)* "."
Text <- Sentence (" " Sentence)*

뒤의 기호에서 구조를 더욱 쉽게 볼 수 있다.그러나 만약 우리가 이러한 규칙에 따라 해석 나무를 구축한다면 자모는 나무의 잎에 나타날 것이다.이것은 식별 임무에 있어서는 이미 충분하지만, 대국에 있어서는 오히려 쓸모가 없다.
만약 우리 언어에 나뭇잎의 자모가 아닌 가장 작은 의미 있는 항목이 있다면 어떻게 될까요?만약 우리가 프로그래밍 언어에 대해 이야기한다면, 이것은 디지털 문자, 키워드, 식별자 등 표기 (또는 어소) 가 될 것이다.

Lexeme is a meaningful linguistic unit that is an item in the vocabulary of a language. Etymology: Greek lexis word

– merriam-webster

만약 우리가 자연 언어를 이야기한다면, 그것은 하나의 단어 (예를 들어 '파리') 또는 하나의 어휘 표현 (예를 들어 '파리') 이 될 수 있다.
흥미로운 부분은 식별 임무와 해석 사이의 미세한 차이를 보는 것이다.실제로 이것은 같은 과정이지만 해석을 유용하게 하기 위해서는 약간의 추가 노력이 필요하다.
이를 실현하기 위해 우리는 문법을 두 부분으로 나눌 수 있다.

어휘-단어 식별을 담당하는 규칙

문법 - 구조 표지를 담당하는 규칙

내가 아는 바에 의하면 이런 분리는 결코 정식으로 규정된 것이 아니다.촘스키의 문법은 PEG, BNF, EBNF가 없다.SDF3 이런 분리가 있다. 나의 관점과 가장 현저한 차이점은 문법 규칙이 규범화layout될 때 문법 규칙에 있는 모든 기호 사이에 어휘 규칙이 아니라 기호를 삽입하는 것이다.문법은 전체 구조를 책임진다. 레이아웃 기호 (빈칸, 줄 바꾸기, 주석 등) 나 그것들의 수량에 무관심하다.
예를 들어 다음 표현식:

let a /* comment */ = 123;

PoV는 문법적으로 다음과 같습니다.

let a = 123;

문법 문법의 비종결부는 문법 문법의 종결부로 쓰인다.이런 방식을 통해 우리는 나무의 잎에 어휘 단위(단어)를 포함할 수 있다.
우리가 문법 규칙에서 허용하는 단말기에는 서로 다른 방법이 있을 수 있다.우리는 어휘 문법이나 다른 기호에 정의된 기호만 허용합니까?
구문 구문에 모든 기호를 사용하려면 먼저 구문 구문에 기호를 정의해야 합니다.

(* lexical *)
if = "if".
then = "then".
end = "end".
(* syntax *)
IfExpression = if Expression then Expression end.

이런 방법은 키워드(또는 보존자)를 가져올 수 있다.또는 이러한 단어(예: SDF3)를 인라인 방식으로 정의할 수 있습니다.

(* syntax *)
IfExpression = "if" Expression "then" Expression "end".

Firs 방법은 그다지 유연하지 않습니다. if 를 키워드로 정의하면 변수로 사용할 수 없습니다. 예를 들어 JS에서 일부 보존 글자는 변수 (식별자) 로 사용할 수 없습니다.

let if = 1;

예를 들어, Lisp에서는 이 문제가 아닙니다.

(def if 1)

실천에서 if를 변수로 사용하는 것은 좋은 생각은 아닌 것 같은데 왜 더 번거롭게 해야 합니까?나는 어휘 문법의 힘이 한계가 있을 수 있다는 것을 증명하려고 했다.알고리즘의 실현에 따라 문법 정보에 접근할 권리도 없을 수도 있다.액세스 권한이 있으면 키워드가 아닌 변수 (식별자) 로 사용할 수 있습니다.
이 예는 어휘 문법 중의 잘못된 뜻을 보여 주었다.자연 언어의 한 예로 그것을 이해하는 것이 더 쉽다. '공격' 이라는 단어다.이것은 명사입니까, 아니면 동사입니까?네가 문장에서 그것을 보지 않으면, 너는 말할 수 없다.
어떻게 어휘의 잘못된 뜻을 해결합니까?알고리즘의 실현 방식에 달려 있다.2단계 해석이 있는 경우

스캐너 - 어휘 문법을 사용하고 표기 생성

해상기 - 스캐너

로 생성된 문법과 표기
광고 솔루션에 의존하는 것 외에 할 일이 없습니다.

어휘 문법에 표기와 일치하는 규칙이 여러 개 있다면 어떻게 해야 합니까?해결 방법 - 최장 영패를 생성하는 규칙을 우선적으로 선택한다.

어휘 문법에 같은 길이의 표기와 일치하는 규칙이 여러 개 있다면 어떻게 해야 합니까?변통 방법 - 어휘 문법에서 가장 먼저 나타나는 규칙(확정적 선택)을 선택한다.

다른 한편, 만약 해상도가 단독 단계의 스캐너 (스캐너 해상도 없음) 가 없다면, 문법에 따라 잘못된 뜻을 해결하고 문제를 제거할 수 있습니다.

구조의 명확성에 관하여

다음 코드를 살펴보겠습니다.

if exp1 then exp2 else exp3 end

다음과 같이 나타낼 수 있습니다(알고리즘과 구문에 따라 다름).

그러나 SDF3과 같은 더욱 밀집된 트리를 생성할 수 있는 알고리즘과 구문이 있습니다.

이런 상황에서 위치에 따라 첫 번째는 조건, 두 번째는'then'지점, 세 번째는'else'지점으로 판단할 수 있다.
이것은 S 표현식으로 작성할 수 있습니다.

(IfExpression exp1 exp2 exp3)

어의학

Semantics is the meaning or relationship of meanings of a sign or set of signs

– merriam-webster

어휘 차원에서 모든'단어'는 의미가 있지만 때로는'상하문'이 없으면 의미를 명확하게 부여할 수 없다.
문법 차원에서 의미는 구조에 있다.
스캐너(태그)는 다음과 같이 태그를 반환합니다.

문자열 - 지정되지 않은 의미

쌍 - 문자열과 규칙에 일치합니다.규칙은 문자열을 어떻게 해석하는지 같은 의미이다.규칙 표시: 키워드(문장부호 포함), 표지부호(변수, 함수, 모듈의 이름), 문자 유형(숫자, 문자열, 문자, 기호 등)