Tokenizer, Lexer, Parser

컴파일은 소스코드를 기계어로 바꾸는 과정이고,

해당 컴파일 과정엔 "구문 분석"이란 파트가 존재한다.

 

구문분석은 소스코드를  AST 트리로 만드는 과정이며,

해당 과정은

코드  -(토크나이저)->  토큰  -(렉서) ->  노드  -(파서) ->  AST 트리

의 과정을 거친다

 

1.토크나이저

- 대상을 토큰으로 쪼갠다

주로 ;나 함수의 {}를 기준으로 쪼개 하나의 명령어/함수를 하나의 토큰으로 바꾼다.

 

2.렉서

- 토큰에 의미를 부여한다.

"let a = 10;"이란 토큰은 let이란 커맨드, a란 변수명, 10이란 변수 값의 지니고있다.

이를 { command : let, name : a, value : 10 }과 같은 형태의 객체로 만든다.

3.파서

while b != 0:
    if a > b:
        a = a − b
    else:
        b = b − a
return a

 

앞에서 구한 노드들을 순서에 맞게 트리의 형태로 만든다.

트리의 형태로 만드는 이유는, 

하나의 트리는 한가지 코드만을 나타낼 수 있기 때문인 것 같다.

같은 노드의 배치를 보고 서로 다른 해석이 나오면 안되기에...

 

 

https://kin.naver.com/qna/detail.nhn?d1id=11&dirId=110203&docId=128692221&qb=YWJzdHJhY3Qgc3ludGF4IHRyZWU=&enc=utf8&section=kin&rank=1&search_sort=0&spq=1&pid=RTXQeF5Y7t8ssbW37cCsssssstG-021386&sid=UWudoHJvLC8AABhVC8Y 

48÷2(9+3)= 288

여담으로, 해당 파서의 프로토콜에 따라 다른 결과물이 나올 수 있다.

 

 

 

 

구문 분석에서 오류 체크는 토크나이저나 렉서가 아닌 파서 단계에서 주로 한다고 한다.

앞 단계에서 오류를 거르고 진행하는게 더 효율적이지 않나 했는데,

구문분석은 오류가 있는 코드를 무조건 제거하지 않고 

주변 코드를 통해 자의적으로 해석하거나 모범 답안을 제공하곤 한다.

이 때문에 마지막 파서 단계에서 오류 체크를 하는게 아닐까.

https://supunsetunga.medium.com/writing-a-parser-syntax-error-handling-b71b67a8ac66

Writing a Parser — Part III: Syntax Error Handling

 

 

 

 

그 외 참조한 글

 

https://gobae.tistory.com/94

[컴파일러] 토크나이저, 렉서, 파서 (Tokenizer, Lexer, Parser)

https://velog.io/@mu1616/%EC%BB%B4%ED%8C%8C%EC%9D%BC%EB%9F%AC-%EC%9D%B4%EB%A1%A0%EC%97%90%EC%84%9C-%ED%86%A0%ED%81%AC%EB%82%98%EC%9D%B4%EC%A0%80Tokenizer-%EB%A0%89%EC%84%9CLexer-%ED%8C%8C%EC%84%9CParse-%EC%9D%98-%EC%97%AD%ED%95%A0

컴파일러 이론에서 토크나이저(Tokenizer), 렉서(Lexer), 파서(Parse) 의 역할